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SUMMARY 


Modern  day  avionics  systems  are  becoming  increasingly  complex  as  the 
demand  for  better  performance  and  higher  reliability /survivability  continue 
to  escalate.  These  demands,  however,  are  being  pressed  in  an  extremely 
cost-conscious  environment.  The  Air  Force  Flight  Dynamics  Laboratory 
has  spearheaded  the  development  of  flight  control  concepts  which  would 
integrate  avionics  subsystems  both  functionally  and  operationally  in  order 
to  cost-effectively  satisfy  the  demanding  performance  and  reliability/ 
survivability  objectives.  While  achieving  measurable  success,  these  efforts 
concerning  development  of  concepts  have  also  uncovered  a  fundamental 
problem:  there  are  no  systematic  design  and  evaluation  techniques  that 
directly  address  an  integrated  control  system  formulation.  The  integrated 
control  design  techniques  and  design  examples  described  in  this  report 
are  the  first  step  in  the  solution  of  this  fundamental  problem. 

These  techniques  and  approaches  were  the  product  of  a  simultaneous 
top-down  investigation  of  the  total  integrated  control  system  design 
requirements  and  a  bottom-up  exercise  of  specific  techniques  on  tractable 
subsets  of  integrated  control  system  configurations.  In  summary,  we  believe 
the  following  accomplishments  of  this  investigation  are  significant  for 
ultimately  realizing  the  fruits  of  integration: 

•  A  total  systems  approach  methodology  and  computer-aided 
design  tool  for  integrated  flight  control  design  and  evaluation 
has  been  formulated.  This  methodology  is  a  composition  of 
classical  system  design  steps  and  system  performance. 
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reliability /survivability,  packaging,  and  cost  evaluation  techniques 
assembled  for  interactive  computer-based  execution.  These 
techniques  not  only  aid  in  integrated  flight  control  system  design 
but  also  provide,  as  outputs,  system  evaluation  measures  for 
demonstrating  the  value  of  integrated  control.  In  addition,  this 
formulation  could  be  used  as  the  foundation  and  framework  for 
establishing  design  specifications  for  future  systems. 

An  integrated  flight  control  system  interactive  sensor  integration 
program  (ISIP)  was  developed,  demonstrated,  and  installed  on 
the  Air  Force  computer.  This  program  addresses  the  sensor  re¬ 
quirements  of  the  flight  control,  guidance  and  navigation,  and 
weapon  delivery  functions  as  directed  interactively  by  the  designer 
and  the  mission,  the  system  configuration,  cost,  power,  weight, 
volume  constraints,  and  total  system  performance.  The  demonstration 
program  contains  performance*  reliability,  size,  power,  weight, 
cost  data  for  gyros,  accelerometers,  radars,  seekers,  and  air 
data  systems  in  addition  to  analysis  tools  for  evaluating  navigation 
system  accuracy,  probability  of  target  acquisition,  and  probability 
of  kill  for  selected  targets  and  weapons.  Although  only  a  subset 
of  the  integrated  flight  control  problems,  this  program  dramatically 
illustrates  the  capability  of  an  interactive  design  technique  and  the 
payoffs  of  integrated  control. 


Despite  a  significant  first  step,  many  steps  still  remain  to  be  undertaken 
to  achieve  a  comprehensive  integrated  control  design  technique.  The 
structure  and  the  methodology  have  been  formulated.  The  power  of  computer- 
aided  design  has  been  demonstrated.  Additional  efforts  are  required  to 
apply  the  computer-aided  ability  to  a  larger  part  of  the  design  structure 
and  methodology.  These  efforts  should  attack  two  fronts.  First,  additional 
analysis  techniques,  particularly  those  addressing  reliability /survivability, 
need  to  be  exercised  and  refined  with  respect  to  computer-aided  implementations 
Second,  the  proof  of  the  ultimate  advantages  of  the  integrated  control  design 
techniques  and  ultimately  the  value  of  integrated  control  resides  largely  in 
the  span  and  quality  of  the  data  bases.  It  is  recommended  that  the  Air  Force 
begin  developing  more  comprehensive  data  bases  built  upon  the  sensor  data 
base  developed  in  the  program. 
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SECTION  1 


INTRODUCTION 

1.1  NEEDS  AND  OBJECTIVES 

The  need  for  integration  of  systems  that  aid  or  control  the  flight  and 
missions  of  aircraft  has  existed  since  the  invention  of  aircraft.  As  the 
aiding  systems  have  become  more  sophisticated,  the  problem  of  integra¬ 
tion  has  become  more  challenging.  Today  system  integration  requires 
the  application  of  modern  control  theory  to  achieve  the  coordinated 
performance  and  simplified  management  desired  for  aircraft.  Further¬ 
more,  these  integration  goals  must  be  achieved  while  conforming  to  the 
significant  and  conflicting  limitations  that  are  being  imposed  on  factors 
such  as  cost,  size,  weight,  failure  rates,  availability,  and  vulnerability. 

It  is  only  through  top-down  stagewise  system  development  and  the 
application  of  advanced  system  design  principles  and  techniques  that  both 
the  goals  and  constraints  can  be  satisfied. 

Integrated  control  is  the  mechanization  that  harmonizes  the  control  of 
flight  system  and  vehicle  dynamics.  During  the  research,  management 
planning,  and  conceptual  design  of  integrated  control  of  flight  (ICOF)  systems, 
the  time  required  for  trade-off  and  evaluation  studies  of  system  concepts 
must  be  minimized.  The  level  of  design  details  investigated  must  be 
curtailed  without  unduly  compromising  the  accuracy  of  the  estimated 
performance  and  the  physical  and  cost  characteristics  of  the  conceptual 
designs . 


The  objective  of  this  study  is  to  provide  an  appropriately  efficient  concept 
design  methodology,  to  develop  integrated  control  design  techniques  (ICDT) 
and  to  demonstrate  their  utility  on  ICOF  conceptual  design  examples. 

This  document  is  the  final  report  on  the  investigations  and  results  of  the 
ICDT  project.  The  flow  of  the  design  methodology  has  been  defined,  the 
techniques  required  for  implementation  selected,  and  examples  of  the 
applications  of  the  techniques  have  been  illustrated. 

The  road  map  to  complete  the  development  of  the  ICDT  methodology  includes 
subsequent  projects  to  develop  the  data  banks  required  to  support  the  design 
techniques  and  to  develop  the  executive  control  program  that  would  permit 
a  systems  engineer  using  an  interactive  computer-based  approach  to  design 
and  evaluate  an  ICOF  system. 

One  example,  showing  the  design  process  for  an  ICOF  sensor  set,  was 
carried  all  the  way  through  to  an  interactive  design  implementation  and 
demonstration. 

1.2  SEMANTICS  AND  SYNOPSIS 

The  shaping  of  the  methodology  flow  to  achieve  an  efficient  and  effective 
design  process  required  the  application  of  recently- conceived  system  design 
principles.  These  principles  or  approaches  are  listed  in  Table  1  along 
with  the  benefits  they  bring  to  system  design.  Descriptions  of  these  design 
approaches  are  provided  in  the  following  paragraphs. 
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1.2.1  Top-Level  Design 


Top-level  design  refers  to  a  system  design  process  that  develops  the  details 
of  a  design  only  far  enough  to  provide  for  a  reasonably  accurate  estimation 
of  its  cost  and  effectiveness  characteristics.  This  process  is  appropriate 
for  the  program  planning  and  concept  definition  stages  of  system  development, 
as  indicated  in  the  system  design  morphology  chart.  Figure  1.  It  examines 
all  the  major  trade-offs  in  system  implementation  and  utility  and  defines 
the  system  architecture.  The  outputs  of  the  process  are  system  concept 
descriptions  and  development  plans  as  used  to  generate  requests  for 
proposals  (RFPs),  planning  documents,  or  type  A  and  B  (top-level)  system 
and  subsystem  specifications. 

Top-level  design  does  not  provide  a  sufficiently  detailed  description  to 
begin  the  production  and  interfacing  design  of  subsystem  components.  It 
does  set  the  stage,  however,  for  the  detailed  design  process  that  leads  to 
production. 

1.2.2  Integrated  Control  Design 

The  objective  of  integrated  control  design  is  to  develop  a  system  having 
reduced  size  and  complexity  or  improved  performance,  or  both,  relative 
to  a  system  developed  by  direct  integration  of  dedicated  subsystem  designs. 
The  achievement  of  these  integrated  control  design  goals  requires  the 
application  of  some  or  all  of  the  integrated  design  considerations  described 
in  Table  2.  The  objectives  of  each  design  approach  considered  are  also 
indicated.  The  approaches  apply  to  the  integration  of  components,  sub¬ 
systems,  and  functions. 
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System  Development 


TABLE  2.  INTEGRATED  CONTROL  DESIGN  APPROACHES 


roaches  Objectives 

1.  Subsystems  integration  to  obtain  a  Control  to  mission 

multi-function  control  system  objective  rather  than 

subsystem  optimization 


Integrated  Control  of  Flight  System 


Weapon  control - ^ 

i'.Uccuveness  mgmt."  ^ 

.  Integration  of  basic  sensing,  data  processing, 
or  actuation  functions 


eliminate  redundant 
components 


3.  integration  of  sensed  data  through  filters  to 
improve  signal  accuracy  or  information 
content 


Improve  signal 
accuracy  and  system 
performance 


4.  Integration  by  use  of  multi-function  components  Reduce  size  and 

cost,  of  components 


Integration  of  processed  subsystem  signals 
to  be  sent  to  actuators 


Simplify  signal 
distribution  and 
limiting 


An  indication  of  the  functional  differences  between  these  two  system  integration 
approaches  is  presented  in  Figure  2.  Integration  of  the  sensing  and  processing 
functions  for  two  of  the  subsystems  is  indicated.  These  integrations  would 
likely  lead  to  reductions  in  size  and  cost  for  the  system  designed  through 
integrated  control. 

1.2.3  Structured  Design 

As  used  in  this  project,  structured  design  refers  to  a  design  process  in 
which  each  step  is  part  of  a  carefully  structured,  logical,  and  orderly 
procedure.  Structured  design  also  implies  a  set  of  guidelines  that  describes 
how  to  do  each  step  as  well  as  what  to  do. 

1.2.4  Top-Down  Design 

Top-down  design  is  a  structured  design  process  that  is  started  by  decomposing 
the  top-level  system  requirements,  as  they  relate  to  mission  goals,  down 
to  subsystem  requirements  and  then  to  component-level  requirements  as 
shown  in  Figure  3.  A  system  designed  by  meeting  these  component  re¬ 
quirements  is  thus  assured  of  meeting  the  top-level  (mission/system) 
goals.  In  contrast,  a  bottom-up  system  design  starts  with  the  selection  of 
components  to  meet  traditional  or  specified  subsystem  requirements  that 
are  not  derived  from  the  specific  mission  goals.  The  system  resulting 
from  the  integration  of  these  components  may  be  an  overkill  or  an  underkill 
when  evaluated  relative  to  the  mission  goals,  and  iterations  of  the  design 
will  be  required. 


A.  INTEGRATION  OF  DEDICATED  SUBSYSTEMS 


AIRCRAFT  STATE: 

POSITION 
VELOCITIES 
ATTITUDES 
ANGULAR  RATES 
ACCELERATIONS 


B.  INTEGRATED-CONTROL  DESIGN 


AIRCRAFT  STATE: 

POSITION 
VELOCITIES 
ATTITUDES 
ANGULAR  RATES 
ACCELERATIONS 


Figure  2.  Contrast  in  System  Design  Approach 
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ICDT  TOP-DOWN  DESIGN 


REQUIREMENTS  SOLUTIONS 


DESIGNED  AT 
LOWEST  LEVEL 
TO  MEET  DECOMPOSED 
HIGH  LEVEL 
REQUIREMENTS 


BOTTOM-UP  DESIGN 
REQUIREMENTS  SOLUTIONS 


Figure  3.  Contrasts  Between  Top-Down  and  Bottom-Up  Design 
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Top-down  design  with  its  procedure  of  decomposition  of  requirements  also 
provides  a  more  equitable  or  unbiased  allocation  of  functions  between  the 
data  processing  and  non-data  processing  parts  of  the  system  and  between 
the  hardware  and  software  than  bottom-up  design  provides. 

1.2.5  Computer-Aided  Interactive  Design 

In  addition  to  the  usual  meaning  of  this  terminology  (designer /methodology 
interaction  implemented  by  an  interactive  graphics  terminal  and  a  man- 
machine  oriented  executive  program),  another  dimension  is  added  as  it  is 
applied  to  ICDT.  The  added  meaning  is  compression  of  the  design  process 
from  many  participants  using  scattered  resources  to  one  individual  interacting 
with  a  unified  collection  of  techniques  and  data  banks  as  shown  in  Figure  4. 
This  design  process  contrasts  in  many  ways  with  the  present  slower  and 
costlier  team-performed  system  concept  definition  illustrated  in  Figure  5. 

The  present  procedure  requires  many  design  specialists  and  their  techniques 
and  data  banks  in  addition  to  the  system  engineer,  who  must  interact  with 
all  of  them  repeatedly  to  accomplish  the  concept  definition. 

1.2.6  ICDT  Demonstration  Program 

The  overall  objective  of  the  demonstration  program  is  to  show  that  integrated 
control  design  techniques  (ICDT)  methodology  is  a  viable  approach  and  that 
it  works.  The  demonstration  program  is  a  prelude  to  the  large  scale  develop¬ 
ment  of  ICDT.  The  specific  objectives  of  the  demonstration  program  are: 

•  To  focus  attention  on  integrated  sensor  system  design 

•  To  develop  specific  algorithms  for  selection  of  sensor  candidate  sets 
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The  System  Concept  Definition  Process 


•  To  implement  the  algorithms  on  the  interactive  computer 


•  To  develop  a  preliminary  mission  and  sensor  data  base 

•  To  demonstrate  the  integrated  sensor  set  design 

The  integrated  sensor  set  design  process  implemented  on  the  interactive 
computer  is  illustrated  in  Figure  6.  Simplified  mission  and  sensor  data 
bases  are  developed  to  demonstrate  the  design  of  integrated  sensor  sets. 

In  the  first  step  of  the  design  process  the  required  mission  parameters 
(COF  functions  needed  for  the  mission,  the  mission  trajectory  parameters, 
sensor  requirements,  etc. )  are  specified  using  the  mission  data  base. 

In  Step  2,  the  projected  measurement  requirements  for  the  various  COF 
functions  are  integrated  to  form  projected  measurement  requirements  for 
the  mission.  This  data  is  used  in  Step  3  to  generate  candidate  sensor 
sets  with  the  help  of  the  sensor  data  base.  In  Step  4,  the  navigation  and 
weapon  delivery  performance  is  evaluated  for  the  candidate  sensor  sets 
to  check  whether  the  required  performance  has  been  obtained.  Optimization 
of  the  sensor  set  design  is  made  by  the  designer  in  Step  5  to  trade  off  per¬ 
formance  against  cost,  weight,  and  other  sensor  characteristics. 

In  spite  of  the  limited  mission  and  sensor  data  base,  the  demonstration 
program  has  proved  effective  in  designing  integrated  sensor  sets  to  meet 
the  specified  mission  requirements.  In  addition  it  has  proved  useful,  in 
the  simple  designs  generated  by  using  the  program,  towards  demonstrating 
the  advantages  of  integrated  vs  nonintegrated  sensor  sets.  The  demonstration 
program  is  currently  operational  on  the  Honeywell  and  ASD  computers.  The 
description  of  the  ICDT  demonstration  program  and  an  illustrative  example 
for  integrated  sensor  set  design  are  given  in  Section  4.0. 
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Figure  6.  Integrated  Sensor  Set  Design  Process 


SECTION  2 


APPROACH 


The  development  of  the  integrated  control  design  (ICD)  methodology  flow 
and  the  collection  of  techniques  required  to  implement  the  methodology 
were  accomplished  by  performing  the  following  set  of  tasks: 

•  Technology  survey 

•  Methodology  flow  definition 

•  Selection  of  a  technique  for  system  effectiveness  evaluation 

•  Collection,  development,  and  correlation  of  system  design 
techniques 


The  objective  of  each  task  is  discussed  below  and  the  results  are  discussed 
in  Section  3. 

2.1  TECHNOLOGY  SURVEY 

The  technology  survey  was  undertaken  to  gather  supplemental  background 
and  resource  information  on  system  design  methodologies  and  on  the 


analytical  techniques  or  models  that  might  be  applicable  to  integrated 
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control  design.  The  resulting  references  are  listed  below. 


A.H.  Agajanian,  "A  Bibliography  on  System  Performance  Evaluation,  "  Computer, 

Vol.  8,  No.  11,  November  1975. 

2 

Algirdas  Avizienis,  "Toward  a  Discipline  of  Reliable  Computing,  "  presented  at 
IFIP  Conference  on  Reliable  Computing  and  Fault  Tolerance  in  the  1980's,  London, 
England,  Sept.  26-29,  1979. 

-iJohn  deS.  Coutinho,  Advanced  Systems  Development  Management,  New  York:  Wiley 
1977.  ~  "  " 

4 

Gerald  J.  Hahn  and  Samuel  S.  Shapiro,  Statistical  Models  in  Engineering,  New  York: 

W  iley ,  1967.  ~  ~  ~ ~ 

5 

K.  C.  Kaput  and  L.R.  Lamberson,  Reliability  in  Engineering  Design,  New  York: 

Wiley.  1977.  " 

g 

Melvin  B.  Kline,  "introduction  to  Systems  Engineering:  Lecture  Notes,  "  Monterey, 
CA:  Naval  Postgraduate  School,  1979. 

7 

- ,  "Software  and  Hardware  R&M:  What  Are  the  Differences  ?  "  Reprint 

presented  at  Reliability  and  Maintainability  Symposium,  San  Francisco,  CA,  Jan. 
22-24,  1981. 

g 

Richard  de  Neufville  and  Joseph  H.  Stafford,  Systems  Analysis  for  Engineer  and 
Managers.  New  York:  McGraw-Hill,  1971. 

g 

William  D.  Rowe,  An  Anatomy  of  Risk,  New  York:  John  Wiley,  1977. 

°Andrew  P.  Sage,  Methodology  for  Large  Scale  Systems,  New  York:  McGraw  Hill, 
1977. 

^Stanley  M.  Shinner,  Techniques  of  System  Engineering,  New  York:  McGraw  Hill, 

1967. 

2 

John  H.  Wensley,  Leslie  Lamport,  Jack  Goldberg,  etal.,  "SIFT:  Design  and 
Analysis  of  a  Fault-Tolerant  Computer  for  Aircraft  Control,  "  Proceedings  of  the 
IEEE,  Vol.  66,  No.  10.  October  1978. 

^Ng  Ying-Wah  and  Algirdas  Avizienis,  "ARIES  76  Users  Guide,  "  UCLA  Eng.  Rpt.  7894, 
Los  Angeles,  CA :  Computer  System  Synthesis  Group,  School  of  Engineering  and 
Applied  Science,  UCLA,  Dec.  1978. 
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Major  conclusions  are: 


1.  No  current  or  pending  developments  were  found  that  were  intended 
to  provide  a  systems  design  methodology  for  integrated  control  of 
flight  (ICOF)  systems  at  the  concept  definition  level  of  design. 

2.  Design  techniques  for  control-of-flight  systems  exist  in  the 
literature,  but  they  have  been  developed  primarily  for  the  detailed, 
full-scale  stage  of  system  design.  These  techniques  need  review 
and  modification,  such  as  simplification  with  respect  to  detail  and 
upgrading  with  respect  to  data  bank  implementation  in  order  to  be 
applicable  to  the  concept  definition  level  of  design  and  ICOF  appli¬ 
cations. 

3.  The  design  techniques  available  cover  most  of  the  techniques  required 
for  implementing  the  planned  methodology. 

4.  Other  than  flight  control  and  navigation  system  design  techniques 
themselves,  the  most  prolific  and  pertinent  category  of  system 
design  techniques  found  were  those  for  digital  data  processing 
(DDP)  subsystems.  Highly  structured  and  top-down  requirements 
definition  and  system  design  techniques  are  being  developed  for 
these  DDP  subsystems  and  it  is  planned  to  adapt  some  of  them  to 
the  ICDT  design  methodology. 
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2 . 2  METHODOLOGY  FLOW  DEFINITION 


A  generalized  systems  design  methodology  can  be  described  in  five  or 
six  classical  steps. 

1.  Problem  definition 

2.  Functional  requirements  derivation 

3.  Candidate  system  design 

4.  Systems  effectiveness  evaluation 

5.  System  selection/optimization 

The  development  of  a  specific  design  process  for  ICDT  required  structuring 
these  five  major  steps  into  substeps  and  selection  of  analytical  design 
techniques  for  the  substeps.  The  last  four  of  the  major  steps  require 
analytical  techniques  for  developing  the  candidate  system  concepts  and  for 
evaluating  their  effectiveness  and  cost.  These  effectiveness  and  cost 
estimates  then  can  be  compared  with  the  goals  and  constraints  set  in  Step  1 
for  the  factors  involved.  The  analytical  techniques  have  to  be  carefully 
selected  to  accommodate  the  desired  scope  of  design  parameters  and  the 
level  of  quantitative  evaluation  that  matches  the  level  of  design  detail 
desired.  By  constraining  the  overall  design  and  evaluation  methodology  to 
a  consistently  top-level  process,  the  time  and  cost  goals  required  by  pro¬ 
gram  planning  and  concept  definition  were  met. 
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Andrew  P.  Sage,  "Editorial:  A  Case  for  a  Standard  for  Systems  Engineering 
Methodology,  "  IEEE  Transactions  on  Systems,  Man,  and  Cybernetics, 

Vol.  SMC- 7,  No.  7,  1977,  pp.  499-504. 
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2.3  SYSTEM  EFFECTIVENESS  EVALUATION  TECHNIQUES 

2.3.1  Objective 

The  objective  of  this  task  was  to  define  modeling  techniques  to  be  used  for 
evaluating  the  effectiveness  of  candidate  ICOF  systems.  This  evaluation 
is  required  in  Step  3  of  the  integrated  control  design  methodology  (ICDM) 
as  a  design  implementation  tool,  as  well  as  in  Step  4. 

2.3.2  Approach  and  Tasks 


Methods  for  evaluating  system  effectiveness  have  been  developed  and  used 

on  many  different  programs.  The  most  notable  of  these  methods  is  the  one 

defined  by  the  Weapon  System  Effectiveness  Industry  Advisory  Committee 

15 

(WSEIAC).  The  committee  reports  document  their  recommendations 
for  a  system  effectiveness  evaluation  methodology  and  as  such  have  pro¬ 
vided  the  basis  for  most  of  the  subsequent  system  effectiveness  developments. 

These  methodologies  were  modified  as  necessary  for  the  ICDT  study. 

Specific  considerations  addressed  include; 

•  Applicability  to  digital  integrated  control  systems /design 
methodology 


15WSEIAC  Task  Group  II,  Prediction- Measurement;  Summary,  Conclusions, 
and  Recommendations,  Final  Report,  Vol.  1,  AFSC-TR-65-2,  Jan.  1965. 


19 


•  New  system  design  techniques--hardware  and  software 
--Reconfiguration  and  redundancy  management 
--Fault  isolation 

--Fault  tolerance 

•  Pilot  performance 

•  Model  flexibility  for  growth /expans ion  (adding  flight  management 
features) 

•  Identifying  inadequate  areas  of  system  design  and  design/cost 
drivers 

--Reliability 
-  -  Maintainability 
—  Mission  performance 
--Cost 


A  system  effectiveness  evaluation  methodology  was  defined  to  include  the 
above  considerations  in  the  most  efficient  manner.  This  was  accomplished 
by: 

•  Defining  the  detailed  requirements  for  the  ICDT  effectiveness 
evaluation  process 

•  Reviewing/evaluating  existing  models  and  techniques  which 
would  meet  those  requirements 

•  Selecting  applicable  techniques  and/or  defining  modifications 
for  application  to  the  ICDM 
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2.4  TECHNIQUE  SELECTION,  DEVELOPMENT,  AND  CORRELATION 


As  indicated  in  the  introduction,  analytical  techniques  are  required  to 
accomplish  the  quantitative  definitions  and  evaluations  of  the  system 
candidates.  These  techniques  implement  the  last  four  major  steps  of  the 
methodology  flow.  They  were  selected  to  accommodate  the  ICDT  methodology 
objectives  by  screening  them  against  these  constraints: 

•  Input  and  output  parameters  must  be  consistent  with  those 
available  during  the  concept  definition  stage  of  design. 

•  Techniques  must  be  closed-ended  to  meet  economy  and 
efficiency  goals  of  top-level  design. 

The  techniques  recommended  are  identified  in  terms  of  the  models  they 
employ.  The  details  are  given  in  Section  3.0. 
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SECTION  3 


SYSTEM  METHODOLOGY  RESULTS 


This  section  presents  the  results  of  the  ICDT  total  systems  approach 
methodology  development.  The  five  major  steps  in  an  integrated  control- of  - 
flight  system  design  are  presented  together  with  the  analytical  methods 
selected  to  implement  them. 

3.1  METHODOLOGY  FLOW 

The  five  steps  in  the  methodology  flow  and  the  outputs  of  each  step  that 
serve  as  inputs  to  the  next  step  are  shown  in  Figure  7.  These  steps  are 
shown  as  sequential  although  iterations  may  occur  at  any  point  in  the 
process  where  goals  or  constraints  are  not  satisfied. 

As  indicated  previously,  steps  2  through  5  use  analytic  quantitative 
modeling  of  the  system  and  its  dynamics  and  require  analytical  techniques 
for  their  execution.  Step  1,  on  the  other  hand,  is  a  data  collection  process 
and  does  not  depend  on  analytical  techniques.  This  step  can  be  greatly 
aided  by  an  outline  that  formalizes  the  dialogue  needed  to  produce  detailed 
descriptions  of  the  problem  and  of  the  resources  to  be  applied  to  its 
solution. 
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Figure  7.  Methodology  for  ICDT 


As  far  as  the  substeps  within  the  major  steps  of  the  flow  are  concerned, 
steps  1,  2,  4,  and  5  are  fairly  straightforward  and  need  no  further 
description  relative  to  the  methodology  flow  at  this  point.  These  steps 
will  be  discussed  more  fully  later. 

On  the  other  hand,  step  3,  covering  the  design  of  candidate  systems  and  an 
estimation  of  their  life-cycle  costs,  has  some  substeps,  branchings,  and 
potential  iterations  of  the  flow  that  warrant  discussion  at  this  time.  An 
expanded  view  of  step  3  is  presented  in  Figure  8. 

The  input  to  step  3  is  the  system  functional  architecture  and  requirements 
derived  in  step  2.  For  each  functional  architecture  to  be  pursued,  these 
requirements  may  be  considered  as  a  functional  design  if  the  performance 
requirements  have  been  reduced  to  point  values  rather  than  sets  of  ranges 
of  acceptable  values.  This  input  includes  functional  performance  require¬ 
ments  for  each  operational  function  (subsystem),  subfunction,  and  mode. 

It  also  includes  block  diagrams  for  each  subsystem  that  show  the  control 
and  data  flow  requirements. 

Within  step  3  the  first  task  is  to  allocate  the  functions  to  be  performed  by 
each  subsystem  into  the  basic  categories  of  sensing,  data  processing,  and 
actuation.  A  limited  degree  of  functional  integration  may  be  accomplished 
at  this  time  by  looking  across  each  of  the  subsystems  for  redundant  or 
highly  similar  functions  that  can  be  integrated. 


i 
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Figure  8.  Expansion  on  Methodology  for  Step  3 


The  next  task  is  to  combine  the  sensing  and  actuating  functions  into  a 
non-data  processing  subsystem  category  for  implementation  by  a  hardware 
type  of  design  methodology.  The  data  processing  subsystem  that  remains 
is  implemented  by  a  distinctly  different  hardware/software  design 
methodology.  The  hardware/software  nature  of  the  data  processing  sub¬ 
system  requires  a  further  branching  of  the  methodology  flow  as  shown 
in  Figure  9. 

At  this  point  in  the  methodology  flow,  the  system  concept  is  essentially  an 
unintegrated  one  in  the  sense  that  the  interfacing  of  the  sensors,  actuators, 
and  data  processing  components  has  not  been  addressed.  This  interfacing 
design,  substep  (3 i),  must  involve  consideration  of  reliability,  main¬ 
tainability,  and  survivability  as  well  as  capability.  Overall  system  goals 
will  be  set  for  these  four  attributes  during  the  problem  definition.  During 
the  functional  design  process,  however,  only  the  capability  (performance) 
goals  are  decomposed  to  the  component  level.  In  order  to  develop  and 
satisfy  some  subsystem-  and  component- level  goals  for  the  other  attributes, 
a  two-  or  three-stage  iteration  of  the  interfacing  design  substep  is  recommended. 
The  first  stage  would  be  to  consider  a  single- thread  interfacing  of  the 
components  selected  for  the  non-data  processing  and  data  processing 
subsystems.  Analyses  to  determine  the  values  of  reliability,  maintain¬ 
ability,  and  survivability  are  then  carried  out  for  the  single- thread  system 
and  for  a  correspondingly  simple  baseline  maintenance  plan.  The  values 
calculated  are  compared  with  the  system  values  established  during  problem 
definition.  The  differences  can  be  used  as  goals  for  the  second  stage  of 
the  interfacing  design  step.  The  second  stage  would  evaluate  the  use  of 
redundancy  of  the  components  and  their  links  for  improving  reliability 
and  survivability.  Geometrical  separation,  reconfigurability,  and  shielding 
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Figure 


would  be  applied  to  improve  survivability.  The  second  stage  would  also 
consider  built-in  test  provisions  plus  a  modified  maintenance  plan  for 
improving  maintainability.  An  analysis  of  the  second  stage  system  would 
then  show  whether  the  goals  set  during  problem  definition  were  met.  If 
not,  a  third  iteration  would  be  necessary  to  fine  tune  the  interfacing  design 
and  meet  the  system  goals. 

To  complete  the  conceptual  design  of  the  candidate  system,  hardware  and 
software  life-cycle  cost  (LCC)  estimations  are  made.  The  system  is  then 
sufficiently  defined  to  proceed  with  the  effectiveness  evaluation,  step  4, 
and  the  cost-effectiveness  optimization/selection,  step  5. 

3.2  PROBLEM  DEFINITION 

In  Step  1,  problem  definition,  integrated  flight  control  system  mission, 
requirements,  constraints,  operating  policies,  schedules,  technology 
availabilities,  and  any  additional  major  design  driver  must  be  precisely 
defined  and  structured  so  that  meaningful  design  trade-offs  can  be  executed. 
An  example  of  the  topics  covered  by  the  problem  definition  is  given  in 
Table  3. 

The  topics  illustrated  in  Table  3  apply  to  the  design  of  ICOF  systems  for 
military  aircraft  having  either  air-to-ground  or  air-to-air  combat  missions. 
Furthermore,  the  ICOF  systems  covered  by  this  methodology  include  the 
following  specific  subsystems: 


•  Flight  control 

•  Navigation 


restrictions 


•  Weapon  Control 


•  Effectiveness  management 

3.3  DERIVATION  OF  FUNCTIONAL  REQUIREMENTS 

The  functional  requirements  obtained  from  step  2  are  described  as  the 
functional  architecture  desired  plus  the  functional  performance,  control 
flow,  and  data  flow  characteristics  developed  for  the  system.  If  specific 
values  of  the  latter  characteristics  are  established  from  the  derived  sets 
of  acceptable  ranges  of  the  characteristics,  the  requirements  become 
those  for  a  specific  functional  design  corresponding  to  the  architecture. 

No  decomposition  of  the  values  of  the  dependability,  maintainability,  or 
survivability  requirements  from  the  system  level  specified  in  the  problem 
definition  to  the  subsystem  and  component  levels  is  attempted  in  this  step. 
System  capability,  however,  is  decomposed  into  performance  requirements 
at  the  subsystem  and  component  levels  by  the  analytical  techniques  to  be 
described.  The  processes  for  achieving  the  other  system- level  effectiveness 
goals  are  part  of  the  implementation  design  methodology  of  step  3. 

3.3.1  The  Structuring  of  the  Functional  Architecture 

The  structuring  of  the  functional  architecture  starts  with  the  decomposition 
of  the  mission  phases  into  segments  and  events  and  the  establishment  of  a 
time  line.  The  system  functions  prescribed  in  the  problem  definition  are 
then  decomposed  into  subfunctions  and  modes.  By  correlating  the  mission 


segments  and  subsystem  modes,  a  set  of  fully  operational  subsystem  and 
system  states  can  be  established.  Next,  a  system  state  transition  matrix 
(the  fully  operational  system  states  vs  causal  events),  referred  to  as  the 
description  of  a  finite  state  machine  (FSM),  is  generated.  The  FSM 
description  is  the  key  to  developing  the  display  and  control  subsystems 
interface  requirements  with  the  four  subsystems  included  in  the  ICDT 
design  methodology.  The  FSM  description  is  also  needed  to  establish 
the  event  and  information  flow  requirements  to  be  handled  in  part  by  the 
data  processing  subsystem  and  in  part  by  the  pilot  through  his  controls. 

From  the  FSM  description,  the  transitions  of  the  fully  operational  states 
during  the  events  associated  with  the  mission  time  line  can  be  charted. 

This  time  line  forms  the  baseline  for  the  subsequent  degraded  and  failed 
state  analyses  required  to  determine  the  system's  dependability,  main¬ 
tainability,  and  survivability. 

The  system  descriptors  derived  in  this  process  can  also  be  used  to  generate 
the  top-level  functional  block  diagram  of  the  system  which  is  the  primary 
representation  of  the  system's  functional  architecture. 

The  substeps  of  the  structuring  of  the  functional  architecture  just  described 
are  summarized  in  Table  4  and  an  instructive  example  of  how  they  are 
accomplished  and  the  parameters  they  encompass  is  given  in  the  next 
subsection. 
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TABLE  4.  THE  SUBSTEPS  FOR  FUNCTIONAL 
ARCHITECTURE  STRUCTURING 


1.  Mission  and  System  Review  and  Extended  Description 

Phases 

Functions 

Functional  partitioning 
Constraints 

2.  System  Functional  Description  and  Mission  Phase  Decomposition 

Functions  Phases 

Subfunctions  Subphases 

Modes  Segments 

3.  Correlation  of  Mission  Segments  and  System  Modes 

Segments  and  system  modes  ->  System  states  (fully  operational) 

4.  Finite  State  Machine  (FSM)  Generation 

Function  state  transition  matrix 
(System  states  vs  events) 

5.  System  States  vs  Mission  Timeline 

6.  Top-Level  Functional  Block  Diagram  of  System 

Functional  interfaces 
Information  flow 
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3 .  3 . 1 . 1  Illustrative  Example  of  Functional  Architecture  Structuring- - 


3.  3. 1.1.1  Mission  and  System  Definitions  from  Step  1--In  Step  1, 
the  problem  definition,  the  illustrative  example  established  that  the 
system  to  be  conceptually  designed  is  a  control  of  flight  (COF)  system 
for  an  existing  (or  fully  designed)  FX  airplane  and  that  the  COF  system 
is  to  provide: 

•  A  flight  control  function 

•  A  navigation  function 

•  A  weapon  delivery  function 

•  An  effectiveness  management  function 

The  FX  (fighter)  airplane  mission  consisted  of  these  phases: 


1. 

Take-off 

5. 

Detect/acquire /attack  target 

2. 

Climb 

6. 

Assess/depart 

3. 

Cruise 

7. 

Return 

4. 

Penetrate 

8. 

Approach  /land 

For  this  illustrative/instructive  example  the  focus  will  be  on  the  critical 
number  5  phase,  detect/acquire /attack  target. 
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The  design  of  the  FX  airplane  is  assumed  to  be  complete  enough  that  these 
interface  requirements  and  constraints  have  been  placed  on  the  design 
of  the  COF  system: 

•  The  aircraft  control  surfaces  are  designed  and  their 
characteristics  defined. 

•  The  control  surface  actuators  are  designed. 

•  The  cockpit  displays  and  controls  are  designed  except  for  the 
autopilot  control  panel  and  the  COF-related  panels,  which 
will  be  completed  after  the  COF  design  has  defined  the  flight 
control,  navigation,  weapon  control,  and  effectiveness  management 
subsystem  characteristics  and  interfacing  requirements. 

The  functional  partitioning  just  described  between  the  aircraft  and  the  COF 
system  is  illustrated  for  the  flight  control  function  in  Figure  10. 

3.3. 1. 1.2  System  Functional  Decomposition- -Starting  with  the  four 
COF  functions  required,  decisions  must  be  made  on  the  array  of  sub¬ 
functions  and  modes  that  will  be  needed  to  achieve  the  desired  functional 
performance  characteristics.  For  this  example  the  functional  decomposition 
shown  in  Figure  11  was  developed. 

A  more  detailed  definition  of  the  mission  phases  is  also  required  for  the 
functional  design  development.  These  details  can  be  obtained  by  breaking 
the  mission  phases  into  subphases  and  segments  as  shown  in  Table  5  for 
the  detect/acquire/attack  target  phase  of  the  mission. 
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Control/Aircraft  Functional  Partitioning 


COF  SYSTEM 


TABLE  5.  DECOMPOSITION  OF  MISSION  PHASE  NUMBER  5 


Detect 

Acquire 

Attack 

Subphascs  1.  Straight  ;»nd 
level  flight 

2.  Dive  for  acquisition 

It.  Attack  target 

Segments  a.  Transition  to 
straight  and 
level  flight 

a.  Hold  straight  and 
level  flight 

a.  Hold  flight  path 

b.  Hold  straight 
and  level  flight 

b.  Hitch  over  to  dive 
path 

b.  Track  target 

e.  Acquire  target 

e.  T ransition  to 
pull-up 

d.  Hold  flight  path 

d.  l-.xit 

e.  l.xit  (to  straight 
and  level) 

3.  3.1. 1.3  Correlation  of  Mission  Segments  and  System  Modes-- The 
next  substep  is  to  define  the  COF  system  operational  states  through  the 
correlation  of  mission  segments  and  COF  modes.  This  correlation  is 
shown  in  Table  6  for  subphase  2  of  mission  phase  5. 

For  this  mission  phase  and  subphase  we  can  identify  the  following  operational 
states  for  each  COF  function  (subsystem): 

•  Flight  Control  States 

I  Attitude  hold  on;  CWS  off;  SAS  on  (segments  a  and  d) 

II  Attitude  hold  off;  CWS  on;  SAS  on  (segments  b,  c,  and  e) 

•  Navigation  States 

I  Navigate  on;  steering  off  (all  segments) 
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TABLE  6.  SEGMENTS /MODES  CORRELATION  TABLE 


I  Seeker  off;  manual  off;  automatic  off  (segments  a  and  e' 

II  Seeker  on;  manual  off;  automatic  off  (segments  b,  c,  and  d) 


•  Effectiveness  Management  States 

I  Test  on;  prediction  on;  configure  on  (all  segments) 


When  all  of  the  mission  phases,  subphases,  and  segments  are  analyzed  in 
this  manner,  additional  subsystem  operational  states  will  occur  and  some 
of  the  above  states  will  reoccur. 
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3. 3. 1.1. 4  Finite  State  Machine  (FSM)  Generation- -The  FSM  is  a 
state  transition  matrix  which  represents  the  pilot-generated  and  external 
events  that  cause  the  subsystem  state  transitions.  This  matrix  is  developed 
by  first  identifying  the  events  that  cause  the  transitions  between  mission 
segments  as  shown  in  the  following  illustration  for  the  flight  control 
subsystem  for  subphase  2  of  mission  phase  5. 

Then  by  correlating  Tables  6  and  7  with  the  flight  control  subsystem  state 
definitions,  the  FSM  matrix  illustrated  in  Table  8  can  be  developed. 


TABLE  7.  MATRIX  DEFINING  SEGMENT  TRANSITIONS 
CAUSED  BY  EVENTS 


Events 

Subphase  2 
Mission  Segments 

Pilot 

Pushes 

CW 

Pilot 
Turns  on 
Seeker 

Pilot 

Releases 

CW 

Pilot 

Aborts 

Attack 

a.  Hold  straight  and 
level  flight 

b 

- 

- 

- 

b.  Pitch  over  to  dive 
angle 

- 

c 

d 

e 

c.  Acquire  target 

- 

- 

- 

e 

d.  Hold  flight  path 

- 

- 

- 

e 

e.  Exit 

- 

- 

- 

- 

16 

J.E.  Hopcroft  and  J.D.  Ullman,  Introduction  to  Automata  Theory, 
Languages,  and  Computation,  Reading,  Massachusetts:  Addis  on- Wes  ley 
Publishing  Co. ,  1979. 
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TABLE  8.  THE  FSM  MATRIX  FOR  FLIGHT  CONTROL 
DURING  SUBPHASE  2  OF  PHASE  5 


!  Events 

Subphase  2 
Mission  Segments 

Pilot 

Pushes 

CW 

Pilot 
Turns  on 
Seeker 

Pilot 

Releases 

CW 

Pilot 
■  Aborts 
Attack 

I  Attitude  hold  on; 

CWS  off;  SAS  on 

11 

- 

II 

II  Attitude  hold  off; 
CWS  on;  SAS  on 

- 

- 

I 

- 

For  clarity  in  discussing  the  subsequent  steps  in  the  functional  requirements 
definition  process,  the  substeps  for  developing  an  FSM  matrix  for  subphase 
3  of  mission  phase  5  will  be  illustrated  and  used.  The  subphase  3  segments 
and  COF  modes  correlation  in  Table  9  is  developed  from  Figure  11  and 
Table  5. 

The  flight  control  subsystem  operational  modes  for  subphase  3  then  can 
be  defined  as: 

I.  Attitude  hold  on;  CWS  off;  SAS  on  (segment  a) 

II.  Attitude  hold  off;  CWS  on;  SAS  on  (segments  c  and  d) 

III.  Attitude  hold  off;  CWS  off;  SAS  on  (segment  b) 
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TABLE  9.  SEGMENTS  VS  MODES  CORRELATION 
TABLE  FOR  SUBFHASE  3 


The  matrix  showing  the  mission  segment  transitions  caused  by  events 
is  shown  in  Table  10. 

TABLE  10.  SUBPHASE  3  SEGMENTS  VS  PILOT-  OR 
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The  FSM  matrix  for  subphase  3  is  shown  in  Table  11 


TABLE  11.  FSM  MATRIX  FOR  PHASE  5.  SUBPHASE  3 


3. 3. 1.1. 5  System  States  vs  Mission  Time  Line--When  the  entire 
set  of  FSM  matrixes  for  all  the  mission  phases  and  subphases  has  been 
constructed,  a  tabulation  of  them  can  be  made  for  each  COF  subsystem 
as  shown  for  the  flight  control  subsystem  in  Table  12. 

By  combining  the  FSMs  columwise,  a  composite  FSM  for  each  mission 
phase  can  be  obtained  that  will  resemble  these  sketches: 


All  events  All  events 

in  Phase  1  in  Phase  2 


All  States 
Used  in 

All  States 

Used  in 

Phase  1 

Phase  2 
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TABLE  12.  TABULATION  OF  FSMs  FOR  FLIGHT  CONTROL 


Mission 

fluse  1  Hiase  2  I*hase  A  I’hase  4  I’haso  5  Itiase  ti  I’hase  7  Miase  K 

Sul>ph.»st* 

1 

•) 

FSM  hi  a 

KC  States  ? 

1 

m 

4 

X 

Then  by  combining  across  the  phases,  a  composite  flight  control  FSM 
matrix  for  the  whole  mission  can  be  obtained.  An  example  is  shown  in 
Table  13. 

Since  the  events  are  defined  for  the  mission  segments  and  subphases  and, 
therefore,  for  the  phases,  a  mission  time  line  for  the  flight  control  states 
can  easily  be  developed.  An  example  is  shown  in  Table  14. 

3.  3.1.  1.6  Top-Level  Functional  Architecture  of  Sy  stem --By  following 
the  process  just  described  for  the  navigation,  weapon  delivery,  and  effective¬ 
ness  management  functions,  the  mission  time  lines  for  each  of  these 
subsystems  can  be  developed.  These  time  line  vs  operational  state  diagrams 
and  the  information  generated  during  their  development  are  the  functional  i 

I 

i 
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TABLE  13.  THE  COMPOSITE  FLIGHT  CONTROL 
FSM  FOR  THE  WHOLE  MISSION 


AH  pilot  or  external  events  for  Mission 


All  Mission 

Flight  Control  States 

Pitot  switches 
on  power  to 
autopilot 

Pitot  selects 
autopilot  mode 
for  takeoff 

Pilot  transitions 
to  straight  K  level 
for  cruise 

Pilot  turns  on 
auto  steering  and 
weapon  release 

Pilot  notes 
touchdown 

l.  Attitude  Hold  On;  CWS  Off;  SAS  on 

- 

- 

' 

111 

II.  Attitude  Hold  On;  CWS  On;  SAS  on 

- 

- 

1 

IV 

III.  Attitude  Hold  Off;  CWS  Off;  SAS  on 

11 

1 

- 

IV.  Attitude  Hold  ^  ff;  CWS  Off;  SAS  off 

Ill 

- 

' 

- 

- 

TABLE  14.  MISSION  TIME  LINE  VS  FLIGHT  CONTROL  STATE 


data  base  required  for  generating  the  top-level  functional  block  diagram 
shown  in  Figure  12.  This  diagram  illustrates  the  functional  interface,  the 
control  flow,  and  the  data  flow  for  the  COF  system. 


This  data  base  is  also  required  for  starting  the  subsequently  described 
implementation  design  of  the  data  processing  and  non-data  processing 
subsystems.  These  data  are  required  for  defining  the  man-machine  inter¬ 
face  control  of  these  subsystems  which,  in  turn,  affects  their  structuring 
and  functional  partitioning. 

Finally,  this  data  base  is  required  for  initiating  the  system  effectiveness 
evaluation  process  described  in  subsection  3.  5.  The  operational  state 
definitions  and  the  time  line  relationships  are  the  basis  for  developing  the 
degraded  state  definitions  and  for  enabling  the  entire  quantitative  state 
space-based  estimations  of  the  system's  effectiveness  for  the  mission. 

3.  3 . 2  Derivation  of  Control  of  Flight  (COF) 

Functional  Performance  Requirements 

i 

i 

After  the  top  level  COF  functional  performance  requirements  needed  to 
meet  the  mission  requirements  have  been  used  to  derive  the  system  functional 
architecture,  the  next  task  is  to  determine  the  performance  requirements 
for  the  hardware  and  software  to  be  used  in  these  COF  functions.  These 
decomposed  component  requirements  can  take  the  form  of  measurement 
accuracies  (for  example,  the  accuracy  with  which  target  range  is  measured 
by  a  radar),  operational  characteristics  (a  radar  altimeter  measures  the 
altitude  accurately  over  the  range  of  100  ft  to  40,000  ft),  computational 
requirements,  (a  fire  control  algorithm  may  need  an  execution  speed  of 
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1000  instructions  per  second),  and  so  on.  In  general,  the  process  of 
determining  the  functional  performance  requirements  is  an  iterative 
one  and  consists  of  three  major  steps. 

The  first  step  is  to  select  mathematical  performance  models  for  the  various 
functional  components  to  be  used  in  COF  of  the  mission.  For  example,  the 
aircraft's  performance  can  be  described  by  means  of  6  DOF  equations  of 
motion;  whereas,  the  sensor  models  may  consist  of  dynamics  relating 
input/output  of  the  sensor,  with  measurement  accuracy  treated  as  a  parameter. 
This  selection  is  a  very  crucial  step.  The  complexity  of  these  models  will 
affect  the  amount  of  effort  needed  to  evaluate  the  performance  of  the  total 
system.  Too  simple  a  model  for  a  hardware  function  can  result  in  inaccurate 
performance  requirements  for  both  hardware  and  software  functions.  The 
second  step  is  to  select  or  design  the  various  computational  algorithms 
(software)  needed  for  the  COF  functions.  Typical  examples  are  autopilot 
algorithms,  fire  control  algorithms,  etc.  Here  again  the  complexity  of 
the  computational  algorithms  will  determine  the  amount  of  effort  needed  to 
evaluate  the  performance  of  the  overall  system.  The  third  and  final  step 
is  to  select  and  apply  the  analytical  techniques  or  tools  which  can  use  the 
mathematical  performance  models  of  hardware  and  the  computational 
algorithms  of  the  software  functions  to  evaluate  the  system's  functional 
performance  and  its  integrated  mission  performance. 

If  the  mission  requirements  are  not  satisfied,  the  designer  selects  or 
designs  better  computational  algorithms  for  the  software  functions  (this 
change  may  increase  the  amount  of  computation  and  hence  the  size  of  flight 
computer)  or  better  performance  for  the  hardware  functions  (this  may 
increase  the  cost  of  hardware)  to  improve  the  overall  system  performance. 
Occassionally  the  designer  may  need  to  add  additional  hardware  functions 
(such  as  more  sensors)  to  meet  the  mission  requirements. 


47 


In  the  following  subsection,  the  various  modern  analytical  techniques  and 
tools  that  can  be  used  to  determine  the  functional  performance  requirements 
are  given.  This  is  followed  by  generic  descriptions  of  the  top-level  COF 
functions. 


3.3.2. 1  Analytical  Techniques  and  Tools  for  Computing  Functional 
Performance- -As  noted  previously,  many  phases  and  associated  COF  tasks 
are  performed  in  any  specific  mission.  In  particular,  for  a  weapon  delivery 
mission  some  of  the  important  COF  tasks  are  given  in  the  following  list: 

•  Stability  augmentation 

•  Navigation  and  position  determination 

•  Energy  management 

•  Terrain  following,  terrain  avoidance 

•  Air-to-ground  weapon  delivery 

•  Sensor  attitude  control  (Heading) 

•  Landing 

•  Effectiveness  management 

In  order  to  evaluate  the  performance  of  the  overall  system  with  respect  to 
the  COF  tasks  and  to  determine  whether  or  not  it  meets  the  mission 
requirements,  various  analytical  techniques  and  tools  must  be  made 
available  to  the  designer.  This  subsection  presents  briefly  the  analytical 
techniques  and  tools  selected  for  ICDT,  the  mission  area  of  their  application, 
and  the  amount  of  effort  required  to  use  them. 
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3.  3.2.  1.  1  General  Optimal  Control  Theory- -This  theory  is  applicable 
to  dynamic  systems  represented  by  nonlinear  differential  equations  and 
deals  with  the  problem  of  selecting  control  inputs  to  minimize  a  performance 
index  or  a  cost  functional  of  control  inputs  and  states  of  the  system.  Various 
numerical  methods  have  been  developed  over  the  past  20  years  to  solve  this 

class  of  problem.  Prominent  among  them  are  the  gradient  methods  and 

,  .  .  17 

dynamic  programming. 

In  general,  complex  numerical  techniques  must  be  employed  involving  a 

1 8 

large  amount  of  data  and  numerous  calculations.  However,  recent  studies 
have  shown  that  when  advanced  numerical  techniques  are  used  in  conjunction 
with  the  computational  power  of  modern  computers,  reasonable  solutions  can 
be  obtained  for  somewhat  simplified  nonlinear  formulations  of  the  mission 
phases. 

The  development  of  accurate  fire  control  algorithms  for  air-to-air  weapon 
delivery  and  nonlinear  guidance  laws  for  tactical  missiles  demands  the 
use  of  general  optimal  control  methods.  However  for  the  concept  level 
design,  linear  optimal  control  methods  discussed  in  the  next  section  are 
considered  to  be  sufficient. 

3.3,  2. 1.2  Linear  Quadratic  Theory — The  complexities  and  disadvantages 
of  the  general  nonlinear  theory  have  led  to  less  general,  but  more  tractable. 


For  a  detailed  discussion  see  S.  J.  Citron,  Elements  of  Optimal  Control, 
New  York:  Holt,  Rinehard  and  Winston,  1 969". 

P .  M.  Julich  and  A.J.  McPhate,  Optimal  Guidance  Using  Microprocessors 
in  a  Real-Time  On-Line  Environment,  AFATL-TR-77-127,  November  1977. 
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formulations  of  the  optimal  control  problem,  known  popularly  as  the  linear 
quadratic  theory.  Since  most  problems  are  nonlinear,  several  techniques 
have  been  developed  and  used  to  reduce  them  to  a  form  that  can  be  solved 
by  linear  quadratic  theory.  Some  of  these  techniques  are  listed  below: 

•  Eliminate  the  nonlinearities  by  approximating  the  nonlinear  system 
by  a  linear  model 

•  Linearize  the  nonlinear  system  equations  about  a  nominal  trajectory 
(obtained  by  using  nonlinear  equations)  using  small  perturbation 
theory 

•  Linearize  the  nonlinear  equations  about  the  current  value  of  the 
state  and  solve  the  linear  quadratic  problem  on  line  at  various 
points  along  the  trajectory 

Various  software  tools  such  as  KONPACT^0  and  ADAPS2*  have  been  developed 
to  use  linear  quadratic  theory.  KONPACT  represents  an  advanced  computa¬ 
tional  tool  for  performing  modern  control  synthesis,  analysis,  and  design 
of  automatic  flight  control  systems.  In  addition,  it  interfaces  with  the 

aircraft  mathematical  models  produced  from  such  advanced  programs  as 
22 

the  FLEXSTAB.  The  efficient  and  versatile  Armament  Delivery  Analysis 


O.  Anderson  and  J.  B.  More,  Linear  Optimal  Control,  New  York: 
Prentice-Hall,  1971. 

20 

A.  F.  Konar  and  J.  K.  Mahesh,  Active  Control  Synthesis  for  Flexible 
Vehicles,  AFFDL-TR- 75-146,  Vol.  I,  II,  III,  June  1976. 

21 

A.F.  Konar,  Development  of  Weapon  Delivery  Models  and  Analysis 
Programs,  AFFDL-TR-71-123,  April  1972. 

22 

E.  N.  Tinoco  and  J.  E.  Mercer,  FLEXSTAB,  A  Summary  of  the  Functions 
and  Capabilities  of  the  NASA  Flexible  Airplane  Analysis  Computer  System, 
NASA  CR-2564,  December  1975. 
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Programming  System  (ADAPS)  was  developed  to  implement  the  mathematical 
models  for  the  analysis  and  design  of  weapon  delivery  systems.  The  aircraft 
model  accommodates  a  wide  variety  of  air  frame  nonlinear  dynamics  and 
measurement  systems.  The  bomb  model  is  general  enough  for  a  variety  of 
dive  bomb  angles,  release  altitudes,  and  release  speeds. 

The  main  advantage  of  the  linear  quadratic  theory  is  the  multivariable  aspect 
which  makes  it  highly  suitable  for  designing  and  analyzing  integrated  control 
systems.  Any  number  of  sensors  can  be  considered  and  all  available  control 
mechanisms  can  be  used,  including  unconventional  ones  such  as  direct 
side  force. 

In  general,  the  process  of  applying  linear  quadratic  theory  to  the  design  of 
integrated  control  systems  involves  the  following  steps: 

•  Determination  of  aircraft  dynamics--Application  of  linear  quadratic 

theory  requires  knowledge  of  the  entire  system  state  and  of  the 

dynamics  of  the  system  being  controlled.  The  traditional  approach 

consists  of  measuring  dynamic  pressure,  altitude,  airspeed,  mach 

number,  or  some  combination  of  them,  and  using  stored  information 

to  estimate  aircraft  dynamics  as  a  function  of  the  measured 

parameters.  The  other  approach,  resulting  in  somewhat  simpler 
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dynamics,  is  based  on  using  identification  techniques  to 
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J.  Howard,  "The  Determination  of  Lateral  Stability  and  Control  Derivations 
from  Flight  Data, "  Canadian  Aeronautics  and  Space,  Vol.  13,  No.  3,  1967, 
pp  127-134. 


determine  the  aircraft  transfer  function  from  the  observed  response 
of  the  aircraft  itself.  In  most  cases,  however,  the  aircraft 
dynamics  are  an  input  given  to  the  COF  system  designer  by  the 
aircraft  manufacturer. 

•  Determination  of  sensor  dynamics--Since  all  state  variables  of  the 
combined  aircraft  and  sensor  system  cannot  be  measured,  it  is 
necessary  to  estimate  the  values  of  the  missing  variables.  This, 
in  turn,  requires  knowledge  not  only  of  the  aircraft  dynamics  but 
also  of  the  sensor  dynamics  and  noise  characteristics.  Simplified 
transfer  function  models  with  gaussian  white  noise  provide  enough 
accuracy  for  estimating  the  missing  variables. 

•  Computation  of  Kalman  filters-- These  filters  are  used  to  recon¬ 
struct  or  estimate  the  state  variables  of  the  system  not  measured 
directly  by  the  sensors.  Once  the  dynamics  of  the  aircraft  and  the 
sensors  are  defined,  the  computation  of  the  Kalman  filter  gains  is 
straightforward  and  KONPACT  software  is  ideally  suited  for  this 
purpose. 
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•  Selection  of  performance  index  or  cost  functional  to  represent 

the  COF  performance- -This  is  by  no  means  straightforward  and 

may  require  several  iterations  before  a  truly  representative 

performance  index  is  obtained.  Recent  research  efforts  at  Honey- 
,25 

well  have  produced  some  encouraging  results  towards  making 
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G.  L.  Hartmann,  C.  A.  Harvey,  and  C.  E.  Mueller,  Optimal  Linear  Control 
Formulation  to  Meet  Conventional  Design  Specs,  ONR-CR-2 15-238-1,  1975. 
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the  selection  of  the  performance  index  straightforward  by  linking 
it  to  classical  performance  (for  example,  gain  and  phase  margins). 

•  Computation  of  optimal  control  law--The  computation  of  state 
feedback  gains,  to  optimize  the  performance  index,  is  done  by  using 
optimal  control  software  (KONPACT).  The  control  algorithm  will 
consist  of  the  Kalman  filter  dynamics  and  the  state  feedback  gains. 

•  Determination  of  gain  scheduling- -This  is  necessary  to  accommodate 
various  flight  conditions  of  the  aircraft.  This  involves  repeating  the 
computation  of  optimal  control  gains  at  various  flight  conditions. 

Reference  26  contains  a  detailed  application  of  the  above  process  to 
designing  a  control  system  for  the  Drones  for  Aerodynamic  and  Structural 
testing  (DAST)  wing. 


3.3.2. 1.3  Navigation  Error  Analysis  Techniques- -Techniques  are 

available  for  propogating  the  measurement  errors  within  the  navigation  system 

and  for  analyzing  the  effect  of  each  of  these  errors  on  the  system's 

performance  of  the  mission.  In  addition,  Kalman  filtering  techniques  and 

calibration  and  alignment  techniques  can  be  applied  to  reduce  the  effect  of 
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these  measurement  errors  and  improve  the  performance  of  the  system. 
NAVCOV^  is  a  software  tool  that  has  been  developed  to  conduct  navigational 
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J.  K.  Mahesh,  et  al. ,  Active  Flutter  Control  for  Flexible  Vehicles, 
NASA-CR-159160,  November  1979. 
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For  details  see  G.  R.  Macomber  and  M.  Fernandez,  Inertial  Guidance 
Engineering,  New  York:  Prentice-Hall,  1962. 
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H.  T.  Gaines  et  al. ,  Unaided  Tactical  Guidance,  AFATL-TR-78-39,  1978. 
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error  analysis  and  to  design  Kalman  filters  and  develop  calibration  and 
alignment  procedures  to  improve  the  performance  of  inertial  navigation 
systems.  This  software  tool  can  be  used  in  repetitive  fashion  to  determine 
the  functional  requirements  of  an  intertial  navigation  system. 

During  the  preliminary  design  of  an  inertial  system,  it  is  necessary  to 
estimate  its  performance  relative  to  the  mission  for  which  it  is  being 
designed.  Since  critical  components  used  in  the  inertial  system  have 
errors  associated  with  their  performance,  they  will  cause  the  system  to 
have  navigational  errors.  Gyro  and  accelerometer  imperfections,  for 
example,  will  propagate  rate  and  acceleration  measurement  errors  through 
the  system,  causing  the  computed  values  of  vehicle  velocity  and  position  to 
be  in  error.  By  repetitive  application  of  the  NAVCOV  analysis  tool,  the 
gyro  and  accelerometer  error  characteristics  that  can  be  tolerated  for  the 
mission  can  be  determined. 

3.  3. 2. 1.4  Digital  Control  Analysis  Techniques- -These  techniques  can 

be  applied  to  represent  digital  control  systems  and  to  analyze  the  performance 

of  these  systems  as  a  function  of  computational  parameters  (that  is,  word 

2  9 

length,  sample  rate,  and  computational  delays).  Digital  mechanization 

of  COF  functions  on  advanced  aircraft  concepts  makes  the  application  of 
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these  techniques  a  necessity.  DIGIKON  is  a  software  tool  that  has  evolved 


2  9 

For  details  see  A.F.  Konar  and  J. K.  Mahesh,  Digital  Flight  Control 
Systems  for  Tactical  Fighters,  AFFDL-TR-73-119,  June  1974. 
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A.F.  Konar  and  J.K.  Mahesh,  DIGITKON  III  User's  Manual,  F0636-TR3, 
March  1979. 


54 


at  Honeywell  to  conduct  digital  control  analysis  efficiently.  It  can  handle 
the  multiloop,  multirate  control  system  implementations  often  required. 

This  software  tool  is  ideally  suited  for  establishing  the  computational 
requirements  of  the  flight  control  system.  The  details  of  using  DIGIKON 
software  to  analyze  and  establish  the  computational  requirements  of  the 
flight  control  system  are  given  in  Reference  29. 

3.  3,2. 1.  5  Nonlinear  Analysis  Techniques- -Nonlinear  analysis 

techniques  available  for  computing  weapon  delivery  performance  and  guidance 

system  performance  include  traditional  Monte  Carlo  techniques  and  direct 

statistical  analysis  methods.  The  Monte  Carlo  techniques  essentially 

involve  simulating  the  nonlinear  system  (for  example,  6  DOF  equations) 

repeatedly  with  different  random  parameters  each  time  and  then  aggregating 

the  results  to  get  statistical  performance  measures  such  as  Circular  Error 

Probability  (CEP)  and  Probability  of  Kill.  The  main  disadvantages  are 

the  time  required  to  do  trade-off  studies  and  the  computer  execution  cost, 

since  several  hundred  simulations  have  to  be  conducted  to  get  a  reasonable 
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accuracy.  CADET  and  NCAP  represent  software  tools  employing 
direct  statistical  analysis  methods  and  represent  state-of-the-art  methods 
for  analyzing  the  mission  performance. 


J.  H.  Taylor,  Direct  Statistical  Analysis  of  Missile  Guidance  System  Via 
CADET,  Analytic  Sciences  Corporation,  March  1976. 

A.  F.  Konar  and  J.  K.  Mahesh,  Covariance  Analysis  of  Nonlinear  Systems, 
Honeywell  IR&D  Report,  Applied  Research,  Vol.  2,  March  1979. 


The  improvement  in  accuracy  may  not  be  significant  enough  to  warrant  the 
use  of  nonlinear  techniques,  rather  than  linear  analysis,  for  concept 
definition  studies, 

3.  3. 2.  2  The  Flight  Control  Function- -With  respect  to  the  overall  mission, 
the  flight  control  is  an  inner  loop  function.  In  many  of  the  navigation  and 
weapon  delivery  performance  analyses  for  a  mission,  the  flight  control  is 
implicitly  assumed  to  be  perfect.  The  advanced  aircraft  concepts,  namely, 
Advanced  Tactical  Fighter  (ATF),  Control  Configured  Vehicle  (CCV),  and 
Advanced  Fighter  Technology  Integration  (AFTI),  all  reflect  a  continuing 
trend  to  aerodynamic  configurations  that  obtain  high  maneuverability 
and  reduced  drag  by  compromising  the  static  stability  characteristics. 

This  necessitates  stability  and  control  augmentation  in  all  of  the  control 
axes  for  the  safety  of  flight.  Thus  for  the  concept  level  design  of  ICDT,  the 
flight  control  system  may  require  consideration  of  those  functions  which 
are  flight  critical  and  those  which  directly  improve  the  mission  performance. 
Examples  of  these  are  described  briefly  below: 

•  Stability  and  control  augmentation  in  all  of  the  control  axes  for 
aircraft  with  marginal  static  stability 

•  Flutter  suppression  control  to  increase  the  flight  regime  of  the 
aircraft 

•  Gust  alleviation  control  to  reduce  the  effect  of  wing  loads  and 
structural  weights 

•  CCV  control  functions  for  obtaining  lateral  and  vertical  transla¬ 
tions  and  directional  control  without  sideslip  or  angle  of  attack 
(This  improves  the  aircraft  maneuverability  and  the  weapon 
delivery  accuracy. ) 
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•  Terrain  avoidance  control  using  a  combination  of  radar  altimeters 
and  forward-looking  radar  data 

•  Threat  avoidance  control  consisting  of  random  flight  path  changes 
mechanized  to  be  optimum  for  particular  threats  and  flight 
conditions 

•  Automatic  control  functions  (for  example,  heading  control  and 
auto  landing)  for  most  phases  of  the  mission  to  reduce  pilot 
work  load 

•  Digital  mechanization  of  flight  control  to  provide  enhanced 
reconfigurability  and  survivability 

A  block  diagram  of  a  generic  flight  control  system  that  accommodates  the 
flight  critical  functions  is  shown  in  Figure  13. 

3.3.  2.  3  The  Navigation  Function--The  advanced  tactical  fighter  of  the 
1985  to  1990  frame  will  be  equipped  with  some  combination  of  inertial 
navigation,  radio  navigation,  and  alternative  navigation  systems. 

Inertial  navigation  systems  vary  significantly  in  capability.  At  one  end  of 
the  spectrum  are  the  inexpensive,  strapped-down  systems  with  performance 
of  10  nmi/h.  The  electrostatically- supported  gyro  (ESG)  navigators  are 
at  the  other  end  with  performance  better  than  0.  l  nmi/h. 

The  global  positioning  system  (GPS)  provides  a  high  rate,  high  accuracy 
update  of  position  and  velocity.  The  system  is  based  on  an  array  of  satellites 
that  continuously  broadcasts  range  and  position  data  to  a  passive  receiver  on 
the  aircraft.  This  permits  the  computation  of  aircraft  position  and  velocity 
with  errors  less  than  10  feet  and  1  ft/s  respectively. 
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Terrain  Contour  Matching  (TERCOM)  and  Microwave  Radiometer  (MICRAD) 
are  alternative  navigation  systems  that  employ  automatic  checkpoint 
techniques.  TERCOM  senses  the  terrain  profile  with  a  radar  altimeter 
and  MICRAD  senses  the  ground  temperature  profile  with  a  radiometer. 

For  each  checkpoint  map,  the  terrain  profile  or  ground  temperatures  are 
prepared  and  stored  in  the  navigation  computer.  When  the  aircraft 
approaches  the  checkpoint,  the  radar  altimeter  or  radiometer  senses  the 
profile  along  the  flight  path  and  compares  it  with  the  stored  data  to  identify 
the  point  of  best  match.  This  provides  the  position  update  to  the  navigation 
system. 

A  block  diagram  of  the  generic  navigation  system  is  shown  in  Figure  14. 


Figure  14.  Block  Diagram  of  the  Navigation  System 
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3.3.  2.4  The  Fire  Control  Function- -Fire  control  is  a  computational 
function  that  uses  the  data  from  the  navigation  system,  air  data  computer, 
target  sensors,  and  weapon  characteristics  to  aid  the  aircrew  or  pilot  in 
launching  the  weapon  under  optimal  conditions.  To  obtain  very  good  weapon 
delivery  accuracy,  advanced  bombing  concepts  are  used  for  the  unguided 
weapons. 

3.3.  2. 4.1  Continuously  Computed  Impact  Point  (CCIP)  Bombing 
Concept- -This  concept  is  incorporated  in  modern  attack  aircraft  such  as 
the  A- 7,  F-lll,  and  F-16.  The  system  accuracy  depends  on  the  accuracy 
of  the  sensors  measuring  target  range,  wind,  aircraft  velocity,  and  attitude. 
Using  the  sensor  data,  the  fire  control  computer  continuously  determines 
the  current  aircraft  position  and  motion  relative  to  the  target  and  compares 
a  computed  impact  point  with  the  actual  target  position.  The  aircraft  can 
be  maneuvered  in  both  pitch  and  heading  (yaw)  without  disturbing  the  fire 
control  solution.  The  heading  must  be  corrected  before  the  launch  point 
is  reached.  Pitch  maneuvers  are  continuously  entered  into  the  fire  control 
computation  so  that  weapon  release  occurs  at  any  time  the  solution 
is  correct.  Figure  15  shows  a  block  diagram  of  the  CCIP  fire  control 
system. 

3.3.  2.  4.  2  Angle  Rate  Bombing  System  (ARBS)  Concept--This  concept 
depends  on  the  target  tracking  sensor  to  provide  accurate  data  on  the  line- 
of -sight  angle  and  line-of- sight  rate.  This  data  plus  altitude  and  air  speed 
from  the  air  data  computer  are  enough  for  the  fire  control  system  to  provide 
an  accurate,  automatic  release  of  unguided  weapons.  This  system  has  the 
advantage  of  not  requiring  accurate  attitude  information  nor  an  accurate 
measurement  of  target  range.  With  target  tracking  established,  the  fire 


Figure  15.  Block  Diagram  of  the  CCIP  Fire  Control  System 

control  system  provides  target  position  and  azimuthal  steering  information 
to  the  pilot  via  the  visual  display.  Pitch  maneuvers  can  be  made  during 
this  time  and  are  permitted  during  weapon  release.  Figure  16  shows  a  block 
diagram  of  the  ARBS  fire  control  system. 

3. 3.2. 5  The  On-line  Effectiveness  Management  Function — The  on-line 
effectiveness  management  function  is  primarily  for  monitoring  the  operability 
of  the  subsystems  and  for  reconfiguring  them  as  effectively  as  possible  when  a 
failure  or  damage  is  detected  and  identified.  Along  with  these  two  sub¬ 
functions,  the  effectiveness  management  function  predicts  the  probability 
of  mission  success  based  on  the  currently  updated  operability  of  the 
integrated  subsystems.  This  prediction  of  mission  success  probability  will 
be  displayed  to  the  pilot  so  that  he  can  make  management  decisions  to 
continue,  abort,  or  modify  (go  after  alternate  targets)  the  mission. 


Figure  16.  Block  Diagram  of  the  ARBS  Fire  Control  System 

The  effectiveness  management  subsystem  required  for  performing  these 
functions  will  be  a  data  processing  subsystem  implemented  to  perform: 

•  Subsystem  failure  appraisals  based  on  built-in  test  equipment 
(BITE)  measurements.  These  appraisals  will  be  used  to  estimate 
the  operability  states  (full,  degraded,  or  failed)  of  the  subsystems 
which  are  required  for  identifying  the  current  probabilities  of  the 
system's  availability  (A),  dependability  (D),  survivability  (S),  and 
capability  (C). 

•  A  determination  of  the  designed-in  reconfiguration  capability 
that  could  be  used  to  improve  a  failed  or  degraded  state  as  it  is 
detected  and  the  generation  of  reconfiguration  commands  and  the 
identification  of  a  " reoperability "  state  achieved  as  a  result  of  the 
reconfiguration  action  taken 
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•  An  instantaneous  estimation  of  the  current  mission  success 
probability  based  on  the  real-time  computation  of  system 
effectiveness  (E  =  A*D*S*C) 

A  functional  block  diagram  of  an  effectiveness  management  subsystem  that 
will  perform  these  functions  is  presented  in  Figure  17. 

The  failures  monitored  by  the  BITE  measurements  can  be  caused  by 
inherent  hardware  and  software  problems  or  by  effects  of  a  hostile 
environment  such  as  weapon  firing. 

The  algorithms  required  for  performing  the  functions  indicated  in  the 
block  diagram  depend  on  the  reliability,  redundancy,  and  reconfigurability 
characteristics  designed  into  the  subsystems  and  the  components  and  their 
interfacing  units.  The  algorithm  can  be  developed  along  with  the  reliability 
and  reconfigurability  design  which  is  part  of  the  subsystems  interfacing 
design  (substep  31).  A  discussion  of  the  sources  of  design  data  that  will  be 
required  for  developing  the  algorithms  for  each  subfunction  is  given  in  the 
following  subsections. 

3. 3.2. 5.1  Algorithm  Development  for  Failure  Appraisal  and 
Operational  State  Estimation- -During  the  interfacing  substep,  31,  of  the 
implementation  design,  redundancy  is  designed  into  a  candidate  subsystem 
to  meet  the  dependability  goals.  As  part  of  this  redundancy  design,  a 
failure  analysis  is  made  that  relates  specific  component  and  subsystem 
failures  to  a  set  of  operability  states. 
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Figure  17.  Effectiveness  Management  Functional  Block  Diagram 


This  set  of  operability  states  and  the  failures  that  cause  transitions  among 
them  can  be  used  to  form  the  relationships  that  are  the  basis  for  the 
algorithmic  design  of  the  failure  appraisal  and  operational  state  estimation 
subfunction.  The  flow  of  this  process  is  illustrated  as  follows: 


'^REDUNDANCY  > 
DESIGN 

CHARACTERISTICS^ 


FAILURE 

ANALYSIS 


RELATIONSHIPS 
BETWEEN  FAILURES 
AND  OPERABILITY 


IT  1.11*1 


ALGORITHM 

DEVELOPMENT 


The  algorithms  take  the  form  of  a  table  look  up  that  translates  the  identified 
failure  to  the  system's  operability  state.  Once  the  state  is  determined,  it 
is  transmitted  to  the  system  effectiveness  calculation  for  an  estimation 
of  mission  success  probability. 

3.3.2. 5.2  Algorithm  Development  for  Reconfiguration  Appraisal  and 


Commands- -In  addition  to  designing  redundancy  into  the  system  candidate(s) 
during  the  interfacing  design  substep,  31,  reconfigurability  is  incorporated 
to  provide  survivability  as  well  as  additional  reliability.  The  reconfigurability 
required  is  determined  by  the  survivability  analyses  and  design  methodologies 
described  in  Section  3. 4.  4. 3.  The  reconfigurability  design  determines  the 
desirable  and  practical  on-board  switching  of  signals  that  can  achieve  useful 
transfers  of  subfunctions.  This  design  process  includes  a  survivability 
and  reconfigurability  analysis  (similar  to  a  failure  analysis)  that  will  relate 
the  reconfiguration  design  possibilities  selected  to  a  set  of  upgraded 
operability  states  made  possible  by  the  on-board  switching  after  a  failure. 
These  are  identified  as  reoperability  states;  the  relationships  between 
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these  states  and  the  switching  actions  that  cause  them  form  the  basis  for 
the  algorithm's  design  of  the  reconfiguration  appraisal  and  command 
subfunction.  The  flow  of  the  process  for  this  subfunction  is: 


As  in  the  case  of  the  failure  appraisal  subfunction,  the  algorithm  for  the 
reconfiguration  appraisal  takes  the  form  of  a  table  look  up.  Once  the 
reconfigurability  state  is  selected,  switching  signals  are  sent  to  the 
components  or  subsystems  and  the  reconfigured  state  identity  is  sent 
to  the  system's  effective  prediction  subfunction  for  a  subsequent  estimation 
and  updating  of  mission  success  probability. 

3.3.2.  5.3  Interactions  with  the  System  Interfacing  Design  Substep — 
Because  of  the  dependency  of  the  algorithm  development  just  discussed 
(3. 3.2. 5.1  and  2)  on  the  characteristics  of  the  implemented  redundancy  and 
reconfigurability  designs,  it  becomes  necessary  to  interlace  the  functional 
design  of  the  effectiveness  management  subsystem  with  the  system  interfacing 
implementation  design  described  in  subsection  3.4.4.  This  interfacing 
is  done  by  following  the  substeps  illustrated  in  Figure  18. 


representing  A,  D,  S,  and  C  at  the  beginning  of  the  mission  are  stored  in 
an  on-board  computer.  The  elements  of  these  matrixes  or  vectors  are 
the  probabilities  of  changing  from  one  state  to  another.  When  a  failure  and/ 
or  a  reconfiguration  causes  a  change  in  state,  the  affected  elements  of 
the  initial  matrixes  must  be  changed  to  zeros  or  ones  and  a  calculation 
of  the  current  system  effectiveness  can  be  performed  by  a  multiplication 
of  the  matrixes. 

The  accuracy  of  the  mission  success  prediction  depends  on  the  validity  of 
the  elements  of  the  A,  D,  S,  and  C  matrixes  which,  in  turn,  depends  on: 

•  The  accuracy  of  modeling  the  design  characteristics  of  the  system 

•  The  accuracy  of  modeling  the  threat  characteristics 

•  The  concurrency  of  the  elements  with  respect  to  the  system 
configuration,  the  threat  environment,  and  the  mission  plan. 

Consequently,  a  simulator  to  perform  a  recalculation  of  the  elements  of 
the  matrixes  before  each  mission  may  be  required  as  ground  support 
equipment  in  order  to  make  the  effectiveness  management  system  an 
accurate  predictor,  in  addition  to  being  a  reconfiguration  management 
tool. 


3.4  DESIGN  OF  CANDIDATE  SYSTEMS 

The  outputs  of  the  functional  requirements  derivation  are  oriented  along 
the  operational  function  lines  defined  in  step  1.  They  must  be  reoriented 
to  the  basic  data  processing  and  non-data  processing  functional  alignments 
by  judgmental  allocation  before  the  implementation  design  can  begin. 
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3.4.1  Allocation  and  Integration  of  Functional  Requirements  to  the  Basic 
Subsystems  ™  ~~  ' 

The  allocation  and  integration  process  is  diagrammed  for  illustrative 
purposes  in  Figure  19. 

First  the  requirements  for  each  operational  function  are  divided  into  the 
sensing,  processing,  or  actuation  categories  that  can  best  handle  the 
process  involved  and  achieve  the  performance  desired.  Then  any  integrations 
of  these  functions  that  will  eliminate  redundancies  are  made.  Next  the 
resulting  sets  of  sensing  and  actuating  functions  are  allocated  to  the  basic 
non-data  processing  design  category  and  the  processing  to  the  basic  data 
processing  design  category.  The  design  processes  for  these  two  basic 
subsystem  categories  are  distinctly  different  and  the  allocation  of  functions 
must  occur  before  the  implementation  design  can  be  started.  This 
initial  substep  of  the  candidate  system  design  process,  the  functional 
architecture  of  the  candidate  system,  provides  the  basis  for  driving  to  the 
system  implementation  architecture  as  indicated  in  Figure  20. 

The  design  of  the  non-data  processing  subsystem  for  a  COF  system  is 
essentially  a  selection  of  the  best  combinations  of  sensors  and  actuators 
to  meet  the  functional  and  performance  requirements.  A  process  for  the 
selection  of  optimal  combinations  of  sensors  was  previously  developed 


69 


ICDT 

METHODOLOGY 

STEPS 


METHODOLOGY  SUBSTEPS  AND  FLOW 


1. 


2. 


3. 


PROBLEM 

• 

DEFINITION 

• 

• 

FUNCTIONAL 

• 

REQUIREMENTS 

• 

DERIVATION 

• 

• 

• 

CANDIDATE 

• 

SYSTEM 

DESIGN 

• 

MISSION  DESCRIPTION - 

AIRCRAFT  DESCRIPTION - 

COF  FUNCTION  LIST 

MISSION  STATES  AND  SEGMENTS' 
SYSTEM  STATES  -4 - 


FINITE  STATE  MACHINE  -4 - 

DESCRIPTIONS  OF  SYSTEM - 

FUNCTION  AND  INFORMATION- 

FLOW  BLOCK  DIAGRAMS  - 

FUNCTION  PERFORMANCE  -4- 
REQUIREMENTS - 


ALLOCATION  AND  INTEGRATION 
OF  FUNCTIONAL  REQUIREMENTS 

SYSTEM  FUNCTIONAL  *4 - 

ARCHITECTURE 


3 


♦ 


NON-DATA  PROCESSING 

SUBSYSTEM 

IMPLEMENTATION 


SUBSYSTEM 
INTERFACING 
DESIGN  (FOR 


DATA  PROCESSING 
SUBSYSTEM 

FUNCTIONAL  ALLOCATION 


NON-DATA  PROCESSING 

SUBSYSTEMS 

DATA  PROCESSING 

SUBSYSTEM 

INTERFACING 

SUBSYSTEM 

ARCHITECTURE 

ARCHITECTURE 

ARCHITECTURE 

CANDIDATE  SYSTEM  IMPLEMENTATION  ARCHITECTURE  DESIGN 


Figure  20.  How  ICDT  Methodology  Flow  Drives  the  System 
Architecture  Design  (at  Concept  Definition  Level 
of  Detail) 
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and  has  been  adapted  to  the  selection  of  both  the  sensors  and  the 
actuators  for  application  in  the  ICD  methodology.  The  characteristics  of 
various  candidate  sensors  or  actuators  are  pre- stored  in  a  data  bank  and 
then  matched  against  the  functional  and  performance  requirements  and 
against  cost  and  effectiveness  requirements  in  so  far  as  these  requirements 
are  specified  at  the  component  level.  The  match-up  is  performed  in  a 
manner  that  permits  an  integration  of  functions  at  the  component  implementation 
level  by  considering  multi-function  as  well  as  single-function  sensors  and 
actuators  and  storing  their  characteristics  in  the  data  bank.  A  more 
detailed  description  of  the  match-up  methodology  for  the  non-data  processing 
subsystem  design  is  given  in  Section  3.4.2.  This  technique  is  implemented  in 
the  demonstration  example  given  in  Section  4.0. 

The  design  of  the  data  processing  subsystem,  as  illustrated  previously  in 
Figure  8,  is  divided  into  two  separate  branches.  These  branches  are  the 
design  of  the  software  and  the  design  of  the  data  processing  hardware. 

The  design  of  the  software  is  a  unique  process,  but  the  design  of  the  data 
processing  hardware  is  similar  to  and  handled  along  the  lines  of  the 
match-up  design  procedures  for  non-data  processing  subsystems.  Prior 
to  the  branching,  the  data  processing  requirements  must  undergo  a  context 
translation  from  being  expressed  in  operational- oriented  parameters  and 
descriptors  to  being  expressed  in  data  processing-oriented  parameters 
and  descriptors.  This  translation  and  the  separation  of  the  software  and 
hardware  functional  requirements  are  handled  by  a  design  approach 
utilizing  both  finite  state  machine  (FSM)  generation  and  hierarchical 
structuring.  The  methodology  is  more  fully  described  in  Section  3.4.3. 
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3.4.2  Design  of  the  Non-Data  Processing  Subsystem 


As  a  starting  point,  we  have  functional  performance  requirements  derived 
from  the  mission  requirement  of  finding  a  target  and  destroying  it  with 
a  certain  probability  of  success.  The  end  point  is  a  selected  set  of  actuators 
and  sensors  which,  when  interfaced  with  the  data  processing  subsystem,  will 
permit  the  aircraft  to  meet  these  requirements.  The  design  resources  we 
are  starting  with  are  a  known  set  of  available  sensor  and  actuator  hardwares 
and  their  known  or  projected  cost,  reliability,  and  capability. 

To  synthesize  the  sensor /actuator  subsystem,  the  mission  performance 
requirements,  decomposed  into  functional  performance  requirements  at 
the  same  level  at  which  hardware  capabilities  are  characterized,  are  met 
by  finding  the  set  of  components  with  the  highest  value  of  the  figure  of  merit 
being  applied  (maximum  performance,  lowest  cost,  etc. ). 

To  illustrate  the  design  process  more  clearly,  the  requirements  decomposition 
technique  will  be  reviewed.  The  starting  point  is  a  specification  of  all 
missions  for  which  the  aircraft  is  intended  to  be  used  (for  example,  bombing, 
air-to-ground  strafing,  air-to-ground  missile  delivery,  etc.).  Each  of 
these  individual  missions  is  then  described  in  terms  of  functional  segments 
(take-off,  flight  to  target  area,  target  acquisition,  approach,  ordnance  release, 
damage  assessment,  return)  and  mission  performance  requirements  (97 
percent  probability  of  target  destruction  (PD),  99.9  percent  probability 
of  intact  return).  Achievement  of  the  overall  mission  requirements 
will  depend  on  the  ordnance  effectiveness,  assumed  to  be  a  known  quantity, 
plus  achievement  of  certain  performance  levels  for  at  least  some  of  the 
mission  segments.  Examples  could  be  location  and  recognition  of  the  target. 


approach  to  release  point  on  a  minimum  risk  trajectory,  and  release  of 
weapons  at  the  correct  relative  location  with  respect  to  the  target  (R). 

In  each  mission,  therefore,  a  set  of  functional  requirements  relating  both 
to  sensor  and  control  issues  can  be  derived.  This  process  is  then  repeated 
for  all  specified  missions,  and  the  resulting  sets  of  functional  requirements 
are  combined.  There  will  certainly  be  overlap  and  repetition  between 
various  sets;  in  some  cases  the  requirements  for  a  mission  in  one  area 
may  be  more  stringent  than  those  in  another,  and  only  the  more  stringent 
requirements  will  be  retained.  Thus  the  overall  set  of  aircraft  functional 
requirements  will  be  somewhat  smaller  than  the  sum  of  the  sets  of  mission 
functional  requirements. 

The  next  step  is  to  decompose  the  set  of  aircraft  plus  COF  system  functional 
requirements  into  a  set  of  specific  sensor  requirements  and  a  set  of  actuator 
requirements.  Examples  of  the  former  would  be:  acquisition  of  a  target 
at  5  km  with  PD  of  95  percent,  angular  tracking  of  target  during  approach 
to  +5  deg  and  measurement  of  range  to  target  of  +20  feet.  Examples  of  the 
latter  would  be  maintenance  of  aircraft  attitude  during  approach  to  +X, 
maintenance  of  air  apeed  between  235  and  250  mph,  and  performance  of  a 
particular  maneuver  within  a  specified  envelope.  When  this  step  has  been 
accomplished,  the  derived  sets  of  sensor  and  actuator  requirements  have 
been  entirely  decoupled  from  specific  missions  or  mission  segments.  The 
complete  set  of  requirements  is  now  responsive  to  the  overall  aircraft 
mission,  and  there  is  no  longer  a  direct  assignment  of  individual  actuators 
and  sensors  to  specific  mission  functions. 
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At  this  point  we  have  a  specific  set  of  functions  to  be  accomplished  by  the 

actuator  and  sensor  set  to  be  selected.  For  every  single  function,  a 

particular  piece  or  class  of  hardware  is  relevant.  As  an  example,  consider 

target  acquisition.  This  could  be  accomplished  by  the  pilot's  visual 

mechanism,  by  a  radar  set,  or  by  a  forward-looking  infrared  device 

(FLIR).  The  latter  two  sensor  classes  will  each  contain  a  number  of 

specific  types.  Each  type  will  have  specific  capabilities  relating  to 

probability  of  detection  of  different  types  of  objects  as  a  function  of  range, 

background,  weather  conditions,  etc.  Each  type  will  have  a  known  (or 

projected)  cost,  reliability,  repairability,  and  survivability.  Now  consider 

a  set  of  missions  requiring  both  air-to-ground  and  air-to-air  capability. 

Target  acquisition  performance  requirements  will  now  be  specified  for 

2 

two  different  situations,  a  5  m  radar  target  at  30  miles  (aircraft)  and  a 
2 

10  m  target  at  two  miles  against  ground  clutter  (tanks).  These  two 
functional  requirements  are  satisfied  by  finding  a  sensor  or  sensors  with 
capabilities  which  meet  or  exceed  those  required.  If  a  single  sensor  will 
serve  both  purposes,  it  would  be  advantageous  to  select  it.  unless  two  less 
expensive  units  would  have  lower  cost,  and/or  if  redundancy  requirements 
dictate  multiple  units.  Clearly  the  issues  of  reliability,  availability, 
survivability,  and  redundancy  complicate  the  issue  beyond  a  simple 
matching  of  capabilities  and  requirements.  These  issues,  however,  can  be 
dealt  with  as  described  in  the  section  on  subsystems  interfacing  design 
(Section  3.4.4). 
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In  principle,  requirements  decomposition  is  straightforward  and,  when 
accomplished,  permits  an  equally  straightforward  system  selection  and 
specification.  In  practice,  it  is  one  of  the  most  difficult  steps  in  the 
methodology.  All  tools  which  have  ever  been  developed  for  the  design 
and  evaluation  of  sensor  and  actuator  subsystem  effectiveness  work  in  the 
other  direction,  that  is,  bottom- up.  The  components  are  specified 
and  the  performance  resulting  from  their  employment  determined.  Nothing 
has  been  available  which  would  start  from  a  specified  system  performance 
level  and  determine  the  required  component  capabilities. 

Given  the  decomposed  sensor  and  actuator  requirements,  all  that  is  really 
required  for  a  design  process  is  to  establish  a  means  by  which  a  designer 
can  match  up  performance  requirements  with  sensor /actuator  capabilities. 
A  simple  and  direct  way  that  this  could  be  done  would  be  to  exercise 
existing  methodologies  for  the  evaluation  of  the  performance  of  components 
for  a  large  number  of  component  sets  and  then  tabulate  the  results.  This 
component  performance  tabulation  could  serve  as  a  look-up  table  for  the 
computer,  and  an  association  could  immediately  be  made  between  com¬ 
ponent  performance  requirements  and  capabilities. 

The  accuracy  of  this  approach  in  terms  of  meeting  mission  requirements 
will  depend  on  the  fineness  of  the  grid  (how  many  component  data  points  are 
in  the  tabulation).  The  ultimate  accuracy  will  be  achieved  when  the 
component  number  is  infinite,  which  becomes  the  case  for  resident  inverse 
algorithms. 


The  prologue  to  the  design  methodology  then  involves  the  decomposition 
of  missions  to  mission  segments  and  functions  and  the  decomposition 
of  mission  requirements  to  component  requirements.  The  association 
of  sensor  and  actuator  performance  characteristics  with  each  functional 
requirement  can  then  be  accomplished.  The  latter  step  will  be  implemented 
by  establishment  of  performance  and  requirement  tabulations,  and  computer 
look  up  between  them. 

3.4.2. 1  The  Impact  of  Integrated  Control  Systems--What  emerges  from  the 
above  process  is  an  assortment  of  black  boxes  which  can  be  interfaced  as 
efficiently  as  possible  and  tested.  This  study,  however,  is  directed  at  the 
integration  of  control  functions.  In  order  to  design  a  truly  integrated 
sensor /actuator  system,  another  level  of  sophistication  is  required.  Until 
now  in  this  description,  each  sensor /actuator  has  been  considered  to  perform 
complete  functions.  An  inertial  navigation  sensor  would  output  location 
coordinates;  a  radar  would  output  the  range,  angular  coordinates,  and 
cross  section  of  an  object  at  which  it  was  pointed.  An  altimeter  would 
provide  a  reading  of  the  altitude  of  the  aircraft.  Integration  of  functions 
at  this  level  would  involve  either  redundancy  (for  example,  altitude 
determinations  with  a  radar  set)  or  the  sharing  of  processing  capability. 

The  ultimate  aim  of  integration  would  be,  however,  to  utilize  all  of  the 
sensing  and  activating  capabilities  of  all  on-board  hardware,  in  order  to 
optimize  system  survivability  and  reliability  and  minimize  cost  and  weight. 

As  an  example,  consider  the  situation  in  which  the  fire  control  radar 
loses  its  range  gate  but  retains  the  ability  to  measure  the  angular  location 
of  the  target.  From  a  functional  standpoint,  the  sensor  can  no  longer  pro¬ 
vide  complete  target  location  information.  In  a  truly  integrated  system, 
however,  the  target  angular  coordinates  plus  altitude  data  from  the  altimeter 
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and  aircraft  orientation  data  from  the  attitude  reference,  if  available  at  a 
central  processing  location,  could  be  used  to  reconstruct  the  required 
data  to  a  high  degree  of  accuracy. 

It  is  not  conceptually  easy  to  do  component  and  function  integration  at  this 
level.  Different  sensors  and  actuators  operate  on  different  physical 
principles  and  are  designed  for  apparently  divergent  functions.  To  deal 
with  them  on  a  common  basis,  they  must  be  described  in  the  same  set  of 
terms.  The  key  issue  thus  becomes  the  description  of  both  the  performance 
requirements  and  available  hardware  characteristics  in  the  same  language. 

In  principle,  there  would  be  multiple  aircraft  and  target  parameter  sets 
which  could  serve  this  purpose.  In  practice,  the  most  direct  and  least 
confusing  solution  set  usually  proves  to  be  the  lowest  level  set  applicable 
to  locate  the  aircraft  position  in  an  earth- centered  coordinate  system  and  to 
describe  its  orientation  with  respect  to  these  coordinates.  Also  needed  would 
be  the  coordinates  of  any  target  relative  to  the  aircraft  and  to  the  local 
airflow  direction.  In  principle,  if  all  coordinate  parameters  are  known, 
their  first  derivatives  can  be  approximated  by  comparing  successive 
measurements.  In  some  cases  (velocity,  for  example)  the  first  derivative 
plays  such  an  important  role  in  aircraft  function  that  it  must  be  determined 
to  a  higher  degree  of  accuracy  and  a  direct  measurement  is  required. 

These  mission  parameters,  it  should  be  noted,  are  common  to  both  sensors 
and  actuators.  Sensors  determine  the  parameter  values  to  some  degree  of 
accuracy,  and  actuators  alter  them.  Sensors  also  have  associated  with 
them  a  small  set  of  unique  parameters  which  describe  their  ability  to  locate 
a  target  (such  as  field  of  view).  Table  15  presents  a  first-cut  listing  of  the 
parameters  required  to  characterize  the  performance  of  sensors  and 


TABLE  15.  IRREDUCIBLE  PARAMETERS 


Parameter 

First  Derivative 

Actuator 

Latitude 

X 

X 

Aircraft  location 

Longitude 

X 

X 

relative  to  earth- 
centered  coordin- 

Altitude  (absolute) 

ates 

Altitude  (relative  to 

X 

X 

local  topography 

Aircraft  attitude 

Pitch 

X 

X 

(relative  to  earth- 

Roll 

X 

X 

centered  reference) 

Yaw 

X 

X 

Sideslip 

X 

Aircraft  attitude 
(relative  to  local 
air  flow) 

Angle  of  Attack 

X 

Location  of  any 

Azimuth 

X 

X 

other  object  (target) 

Elevation 

X 

X 

relative  to  air  craft 

Range 

X 

X 

Sensor  FOV 

Data  Rate 

Normalized  Spatial 
Resolution 

Normalized 

Detection  Range 

9 


actuators  of  an  avionics  system  at  the  level  required  for  total  system 
integration.  All  parameters  listed  apply  to  sensors.  Those  for  which  a 
direct  determination  of  first  derivative  may  also  be  required  are  indicated 
by  the  presence  of  an  x  in  the  column  labeled  First  Derivative.  Those  which 
are  also  applicable  to  actuators  are  indicated  by  an  x  in  the  Actuator  column. 
The  key  feature  of  the  parameters  in  this  set  is  that  they  are  irreducible, 
that  is,  none  can  be  determined  by  measurement  of  any  combination  of 
others. 

3. 4.2.2  Sensor  Integration  Methodology 

In  order  to  simplify  the  description  of  the  way  in  which  this  parameter  set 
would  be  used  to  design  an  integrated  avionics  system,  let  us  consider  a  case 
in  which  survivabilny  and  reliability  are  not  issues,  and  consider  availability 
to  include  adverse  weather  situations.  Three  steps  are  then  required  to 
achieve  the  objective.  The  first  step  is  to  express  mission  requirements 
in  terms  of  an  irreducible  parameter  set.  This  step  would  begin  with  the 
process,  described  earlier,  of  functional  decomposition.  It  goes  beyond 
this  point,  however,  in  that  the  mission  requirements  are  reduced,  not 
only  to  sensor  and  actuator  functional  performance  requirements,  but  to 
performance  requirements  expressed  in  terms  of  measurement  or  control 
of  the  irreducible  parameters.  In  some  cases,  such  as  that  of  an  altimeter, 
these  levels  are  indistinguishable.  In  others,  such  as  a  FLIR,  or  a  pilot, 
the  level  may  involve  quite  different  parameters. 


Step  two  is  to  catalog  the  performance  capabilities  and  costs  of  the  candidate 
hardware  items  in  this  same  terminology.  When  this  has  been  accomplished, 
step  three,  the  design  of  an  integrated  system,  can  proceed  in  a  methodical 
manner.  This  basically  entails  selecting  components  which  fill  one  or  more 
performance  requirements  in  order  of  increasing  cost  until  all  requirements 
are  met.  In  this  simplified  scenario,  each  mission  set  would  result  in  the 
specification  of  particular  values  to  be  achieved  for  the  measurement  and 
control  of  each  irreducible  parameter.  Each  candidate  hardware  item  would 
be  characterized  by  its  ability  to  measure  or  control  each  parameter  and 
by  its  cost. 

An  example  of  this  catalog  and  of  the  data  to  be  included  for  the  APN-222 
altimeter  is  shown  in  Table  16.  In  Section  a  of  Table  16  the  previously 
defined  irreducible  parameter  set  is  shown  for  this  sensor.  In  this  case 
the  only  parameter  measured  is  relative  altitude.  The  accuracy  obtained 
and  the  range  of  operation  are  shown.  Sections  b  and  c  of  Table  16  indicate 
the  environmental  restrictions  placed  on  sensor  operation  (these  are  in 
the  areas  of  pitch  and  roll  and  temperature  range)  and  the  cost  data. 

These  latter  include  volume,  weight,  and  power  requirements,  as  well 
as  reliability  data  (mean  time  between  failures  would  be  the  desirable 
format  for  this  parameter). 

Preparation  of  the  data  for  the  demonstration  example  has  been  somewhat 
difficult,  because  no  general  tabulation  of  the  required  data  for  all  available 
avionics  equipment  appears  to  be  available.  Fairly  complete  tabulations  of 
APN  numbers  and  descriptions  are  available,  but  the  descriptions  lack  the 
required  detail.  It  will  probably  be  necessary,  therefore,  to  develop  this 
data  piecewise  from  a  variety  of  sources  in  the  next  phase  of  this  design 
methodology  development. 


TABLE  16.  CATALOG  OF  PERFORMANCE  CAPABILITIES 
AND  COSTS 

Device  Designation 
APN-222  Altimeter 


a.  Capabilities 

Parameter 

Value  + 

Rate  + 

Accel  + 

Aircraft  location 

Latitude 

relative  to  earth- 

Longitude 

centered  coordinates 

Altitude  (wrt  earth 

center) 

Altitude  (local  relative) 

5  ft  +  0.  5  percent  alt 

Operating  range 

max  70,  000  ft 
min  0  ft 

Activity  warning 
(high /low) 

Aircraft  attitude 

Pitch 

(relative  to  earth- 

Roll 

centered  reference) 

Yaw 

Aircraft  attitude 
(relative  to  local  air 

Sideslip 

flow) 

Angle  of  attack 

Location  of 

Azimuth 

other  objects 

Klcvation 

(targets)  relative 

R  ange 

to  air  craft 

Sensor  FOV 

Other  sensor 

Data  rate 

parameters 

Normalized  detection  range 
Normalized  spatial  resolution 

b.  Restrictions  ] 

Track  rate 

10’  at  70,000  ft 

Pitch  and  roll 

20°  at  35,000  ft 

Temperature 

On  (  F) 

-55  -  +71 

Off 

-65  -  +05 

Weather 

c.  Cost 

Vol  (in'*) 

168 

18 

Wt.  (lbs) 

6.  5 

2.5 

1.0 

Power  (watts) 

15  *  28  DC 

15  .*  28 

Life  (hours) 

10,000 

Operational  Stability 
(hours) 

1,000 

3.  4.2. 3  Outline  of  Overall  Process 

A  view  of  the  overall  ICDT  design  methodology  highlighting  the  sensor 
subsystem  selection  step  is  presented  in  Figure  21.  it  should  be  noted 
that  the  performance  requirements  derived  by  Steps  1  and  2  may  be  a 
number  of  sets  of  values  for  the  basic  sensor  (or  actuator)  parameters, 
rather  than  just  one.  This  plurality  of  sets  is  due  to  several  factors: 
for  example,  trade-offs  between  performance  for  various  parameters 
are  possible,  which  do  not  affect  the  functional  outcome.  For  some  sensors, 
for  example,  acquisition  range,  data  rate,  angular  resolution,  and  range 
resolution,  can  be  traded  in  various  ways.  Also,  requirements  for 
performance  for  different  parameters  may  not  be  independent.  It  would  be 
possible  in  some  cases,  for  example,  to  relax  angular  rate  accuracy  if 
range  were  known. 

There  will,  generally,  be  more  than  one  set  of  the  candidate  sensor  sets 
which  will  meet  the  sensor  performance  requirements.  The  sensor  selection 
methodology  recommended  for  substep  3G  uses  life-cycle  cost  as  the 
variable  parameter  and  evaluates  the  selected  sets  in  order  of  increasing 
cost. 

3.4.3  Design  of  Data  Processing  Subsystem 

At  this  point  in  the  design  process,  the  mission  and  system  requirements 
have  been  analyzed  and  decomposed  into  system  functions,  subfunctions, 
and  modes.  The  functional  requirements  for  the  non-data  processing 
elements  of  the  system,  particularly  the  sensors  and  actuators,  have  been 
identified.  The  functional  requirements  for  data  processing  elements 
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Figure  21.  ICDT  System  Design  as  Driven  by  Subsystem  Designs 
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of  the  flight  control,  navigation,  weapon  delivery,  and  effectiveness 
management  operational  functions  have  been  determined.  Modes,  displays, 
sensor  inputs,  block  diagrams  for  implementating  the  control  laws,  and 
other  calculations  have  been  specified.  The  values  of  the  parameters  used 
in  the  computations  of  leads,  lags,  and  filters  have  been  estimated.  The 
task  now  is  to  translate  this  information  into  a  format  and  terminology  that 
will  permit  appropriate  analysis  of  the  data  processing  requirements  and 
that  will  facilitate  the  hardware  and  software  implementation  of  these 
requirements. 

Eventually,  the  design  of  the  data  processing  subsystem  will  be  aided  by 
interactive  access  to  a  large  data  base.  A  great  amount  of  experience 
and  data  has  been  accumulated  on  the  computational  requirements  for 
control  of  flight  systems.  This  material  can  be  catalogued  in  a  design 
data  base  and  called  upon  interactively  to  provide  estimates  of  required 
throughput,  memory,  and  so  on.  These  requirements  can  then  be  matched 
to  available  computer  configurations.  These  computer  design  aids  will 
not  be  developed  in  the  following  design  discussion,  but  it  should  be  clear 
how  much  of  the  design  process  may  be  automated. 

3.  4.  3.1  Translation  of  Allocated  Functional  Requirements  into  Data 
Processing  Subsystem  Performance  Requirements — The  ICD 
methodology  for  concept  definition  goes  as  far  as  a  preliminary  design  of 
the  software  but  stops  before  detailed  design  and  coding  begin.  However, 
an  accurate  and  complete  description  of  the  requirements  will  ultimately 
be  needed  to  detail  design,  code,  and  verify  the  software.  Thus,  the  ICD 
methodology  must  produce  preliminary  designs  that  are  described  in  a 
manner  that  allows  convenient  extension  to  detail  when  the  design  process 
is  continued. 


The  design  process  begins  by  reformulating  the  requirements  for  data 
processing  into  a  more  appropriate  format. 

The  following  list  is  compiled: 

•  Each  operational  function,  its  inputs  and  outputs 

•  Assumptions  made  for  each  function 

•  Performance  requirements  that  may  be  the  most  difficult 
to  achieve 

•  Each  interface  between  the  data  processing  functions 
and  the  rest  of  the  system 

•  Any  special  non-digital  data  processing  (for  example, 
analog  backup  systems) 

•  Any  other  assumptions  made  to  complete  the  description 
of  the  requirements 

The  next  task  is  to  translate  these  operational  function  requirements 
into  computational  requirements.  The  process  will  be  explained  by 
following  the  particular  example  of  the  flight  control  subsystem  design. 

The  computing  aspects  of  each  block  in  the  COF  system  block  diagrams 
and  the  rates  of  computation  have  been  determined  in  the  previous  step. 

A  typical  list  of  computational  items  for  the  flight  control  function  is  shown 
in  Table  17.  The  sample  rate  is  generally  taken  to  be  at  least  five  times 
greater  than  the  highest  frequency  of  interest.  Representative  sample 
rates  for  autopilot  functions  are  given  in  Table  18.  In  safety  critical 
systems,  the  required  reliability  is  obtained  by  using  redundant  channels. 


TABLE  17.  DIGITAL  SIZING  ESTIMATES--HDP-5301  COMPUTER 


Memory  Requirements 


Function 

Instr 

Const 

■9 

Computation  Time 

Lag 

13 

1 

2 

30 

Hipass 

13 

1 

2 

30 

Symmetrical  limiter 

12 

1 

- 

18 

Deadband 

7 

1 

- 

9 

Integra  tor /Limiter 

21 

2 

2 

43 

Notch  filter 

23 

4 

4 

66 

Lead /Lag 

13 

3 

2 

41 

Hysteresis  switch 

29 

3 

1 

25 

Synchronizer 

6 

- 

1 

11 

Gain  schedules 

1  Slope  and  2  BPs 

17 

6 

1 

33 

2  Slopes  and  3  BPs 

26 

9 

1 

40 

3  Slopes  and  4  BPs 

35 

12 

1 

47 

2  Slopes  and  IBP 

20 

5 

1 

31 

Fader 

13 

1 

1 

28 

Gain 

1 

1 

8 

Univariate  function 

50 

50 

185 

Bivariate  function 

125 

150 

455 

An  example  of  these  redundancy  requirements  is  shown  in  Table  19.  The 
memory  and  processor  sizing  requirements  can  be  estimated  from  the 
block  diagrams,  from  the  derived  data  illustrated,  and  from  previous 
experience  with  similar  systems.  The  flight  control  example  is  carried 
through  in  Table  20  and  summarized  in  Table  21.  The  four  columns  of 
computation  times  listed  in  Table  20  represent  a  preliminary  allocation 
to  subframes  in  the  usual  rate  structure  executive  program  which  accommodates 
the  different  sample  rates. 


In  this  manner  a  preliminary  outline  of  the  required  calculations  and 
estimates  of  the  computational  load  can  be  obtained  for  each  operational 
subsystem.  The  estimates  rely  to  some  extent  on  previous  experience 
and  knowledge  of  how  these  avionic  computations  have  been  handled. 
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TABLE  19.  REDUNDANCY  MANAGEMENT  REQUIREMENTS 


System 

Sensors 

Electronics 

Servos 

Pitch  SAS 

Fail  Op, 

Fail  Op2, 

Fail  Op, 

Fail  Safe 

Fail  Safe 

Fail  Safe 

Yaw  SAS 

Fail  Op, 

Fail  Op2, 

Fail  Op, 

Fail  Safe 

Fail  Safe 

Fail  Safe 

Roll  SAS 

Fail  Safe--IVlanual 

Fail  Op, 

Fail  Safe-- 

select  functional 

Fail  Safe 

Manual  select  for 

sensor  after  first 

reduced  performance 

failure 

after  first  failure 

Pitch  A/P 

INS  Fail-- 

Fail  Op, 

Same  as 

Select  FRS 

Fail  Safe 

Pitch  SAS 

Roll  A/P 

INS  Fail-- 

Fail  Op, 

Same  as 

Select  FRS 

Fail  Safe 

Roll  SAS 

ADC 

Fail  Op, 

Fail  Op, 

Not  applicable 

Fail  Safe 

Fail  Safe 

A  P\V 

Fail  Safe 

Fail  Op, 

First  fail  Inop 

Fail  Safe 

Inlet 

First  fail-- 

Fail  Op, 

First  fail  Inop 

Manual  select 

Fail  Safe--Monual 

failed  side 

select  failed  side 

Note:  •  Fail  Op^,  Fail  Safe  (System  operational  after  two  failures  and  fails  safe  for 
third  failure). 


•  Fail  Op.  Fail  Safe  (System  operational  after  one  failure  and  fails  safe  for 
second  failure). 

•  Fail  Safe  (System  fails  safe  for  first  failure). 
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TABLE  20.  SOFTWARE  SIZING  ESTIMATES 


F  unction 

Memory 

Requirements 

Computation  Time  -  Milliseconds 

Instr 

Const 

Spad 

S.I.  #1 

S.I.  #2 

S.I.  #3 

S.I.  #4 

Air  Data  Computer 

612 

97 

51 

2.0 

2.0 

Mode  Logic 

500 

10 

20 

0.436 

Pitch  Sas 

1  *  Lag 

13 

1 

2 

0.030 

2  -  Lead* Lags 

26 

6 

4 

0.082 

4  -  Limiters 

48 

4 

0.092 

1  -  Qc  Schedule 

17 

6 

l 

0.033 

4  •  Gains 

4 

4 

0.  032 

1  -  Switch 

3 

0.  009 

SUBTOTAL 

111 

21 

7 

0.258 

0.258 

0.258 

0.258 

Lateral  SAS 

1  -  Hipass 

13 

1 

2 

0.030 

2  -  Qc  Schedules 

34 

12 

2 

0.066 

1  -  Switch 

3 

0.009 

8  -  Gains 

a 

3 

0.  064 

3  -  Limiters 

36 

3 

0.054 

1  -  Notch 

23 

4 

4 

0.066 

SUBTOTAL 

117 

28 

8 

0.289 

0.  289 

0.  289 

0.289 

Pitch  Autopilot 

2  -  Lags 

26 

2 

4 

0.  060 

2  -  Hipass 

26 

2 

4 

0.  060 

1  -  Notch 

23 

4 

4 

0.  066 

l  -  Integrator 

21 

2 

2 

0.  043 

1  -  Variable  Lag 

54 

13 

4 

0.  110 

5  -  Limiters 

60 

5 

- 

0.  090 

2  -  Synchronizers 

12 

- 

2 

0.  022 

l  *  Fader 

13 

1 

l 

2  -  Hysteresis  Switch 

58 

6 

2 

0.  050 

3  -  Ps  Schedules 

38 

18 

3 

0.  098 

3  *  Gain  Schedules 

105 

36 

3 

0.  141 

1  -  2  Var.  Schedule 

63 

22 

2 

0.  097 

29  -  Gains 

29 

29 

. 

0.  232 

12  -  Switches 

36 

- 

- 

0.  108 

SUBTOTAL 

562 

140 

31 

1.205 

1.205 

Roll  Autopilot 

1  *  Integrator 

21 

2 

2 

0.043 

2  *  Synchronizers 

12 

- 

2 

2  •  Limiters 

24 

2 

. 

0.  036 

1  -  Mach  Schedule 

17 

6 

1 

0.033 

8  -  Gains 

8 

8 

• 

0.  064 

1  »  Switch 

3 

- 

0.  009 

SUBTOTAL 

87 

18 

5 

0.207 

0.207 

90 
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TABLE  20.  SOFTWARE  SIZING  ESTIMATES  (CONCLUDED) 


F  unction 

Memory 

Requirements 

Computation  Time  -  Milliseconds 

Instr 

Const 

ES91 

S.l.  #1 

S.l.  *2 

S.l.  #3 

S.l.  #4 

Inlet  Control  System 

PtPg  and  Mo  Computations 

400 

60 

30 

1.09 

0.  365 

18  Analog  Inputs 

54 

18 

0.09 

6  Analog  Inputs 

18 

6 

0.03 

2  Discrete  Inputs 

4 

0.01 

4  Discrete  Outputs 

8 

0.015 

6  Bivariate  Functions 

750 

900 

0.91 

1.81 

Same  as 

Same  as 

2  L  nivariate  F unctions 

100 

100 

0.  36 

0.  18 

S.l.  #1 

S.l.  #2 

1  Absolute  Value  with  Threshold 

6 

1 

0.  02 

2  Limiters 

24 

1 

0.  02 

0.02 

3  One  sided  dead  bands 

21 

1 

0.  06 

0.  06 

5  Three  Input  Sums 

3 

0.  026 

0.  026 

1  Lead  Lag 

13 

6 

2 

0.041 

0.  041 

10  Gains 

to 

10 

0.054 

0.  054 

1  l  nstart  Logic 

100 

0.094 

SUBTOTAL 

1515 

1079 

56 

2.80 

2.  576 

2.80 

2.  576 

Subtotals  if  Both  Inlet 

Computations  are  Done 

in  Each  Computer 

3030 

1079 

1 12 

4.  51 

4.  787 

4.51 

4.  <88 

APU 

1  -  Lead  Lag 

13 

3 

2 

0.  041 

1  -  Limiter 

12 

l 

0.018 

1  -  Switch 

3 

0.  009 

2  -  Mach  Schedules 

34 

12 

1 

0.  066 

4  -  Gains 

4 

2 

0.  032 

SUBTOTAL 

66 

18 

3 

0.  166 

0.  166 

BIT 

5301  Self  Test 

186 

10 

2 

0.364 

Power  Supply 

48 

6 

1 

0.  076 

Data  Exchange 

28 

i 

1 

0.  047 

Memorv  Sum  Checks 

54 

3 

1 

Initialization 

Discrete  Input  Test 

75 

u 

1 

0.  131 

Output  Wrap-Arounds 

130 

1 

0.  218 

Servo  Checks 

887 

12 

5 

Pre- 

■Flight 

Sensor  Checks 

221 

6 

6 

Pre- 

■Flight 

SUBTOTAL 

1679 

51 

19 

0.  705 

0.  131 

0.  705 

0.  131 

Executive 

500 

20 

50 

1.27 

1.  27 

1.27 

1.27 

TOTALS 

7381 

1500 

316 

8.  882 

8.902 

8.446 

8.902 
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TABLE  21.  SUMMARY  OF  SIZING  ESTIMATE  (TRIPLE  SYSTEM) 


Memory  Requirements 

Computation  Time  ! 

Function 

Instr 

Const 

Spad 

msec 

Sample  Rate 

Executive 

530 

20 

50 

1.27 

40 

SAS 

250 

50 

20 

0.60 

40 

Autopilot 

715 

160 

40 

1.55/2 

20 

Auto  pilot  warning 

75 

20 

5 

0.20/2 

20 

Air  data 

700 

100 

55 

2.20/2 

20 

BIT  (in  flight) 

1.700 

60 

30 

0.  77 

20 

Mode  logic 

52  5 

10 

20 

0.48/4 

10 

Inlet  control  system 

3,300 

1,080 

112 

2x2.8 

40 

Total 

7.795 

1,  500 

332 

10.34 

Percent  of  capacity 

58.  5 

73.2 

32.4 

41.4 

3. 4.  3.2  Allocation  of  Digital  Prccessing  Subsystem  Performance 

Requirements  to  Hardware  and  Software  Requirements-  -  This 
allocation  of  requirements  is  determined  by  defining  the  interfaces  between 
the  data  processing  functions  and  the  rest  of  the  system  (the  fourth  item  in 
the  previous  list)  and  by  defining  the  interfaces  between  the  hardware  and 
the  software.  Experience  has  shown  that  serious  problems  may  arise 
if  these  interfaces  are  not  well  defined  and  documented.  These  interfaces 
between  system  components  are  often  reflected  in  interfaces  between  data 
processor  design  engineers.  A  large  part  of  the  data  processing  systems 
design  effort  can  be  taken  up  in  communications  between  engineers  on  these 
issues. 


The  goal  of  this  methodology  is  a  preliminary  design  of  the  COF  system 
and  the  basis  for  an  estimate  of  its  costs.  However,  it  must  provide  a 
basic  design  which  can  be  subsequently  extended  to  a  detailed  design. 

During  preliminary  design  it  is  easy  to  commit  errors  of  omission. 

These  are  very  hard  to  discover  in  later  stages  of  detailed  design  and  are 
very  expensive  to  correct  if  they  remain  undetected  until  field  trials. 

Very  often,  after  all  of  the  trade-offs  have  been  made,  the  selected 
preliminary  design  is  taken  as  the  basis  for  subsequent  detailed  design 
without  careful  reviews  of  all  of  the  assumptions  and  technical  factors 
that  went  into  it.  The  preliminary  or  concept  definition  work  is  done 
primarily  to  arrive  at  significant  trade-off  decisions.  There  may  be 
omissions,  inconsistencies,  and  errors  that  will  cause  trouble  later  on 
in  the  process  if  the  methodology  does  not  lend  itself  to  successive 
refinements.  Also,  a  basis  for  the  validation  of  the  final  configuration 
must  be  established  early  in  the  design.  The  approach  outlined  in 
Reference  33  incorporates  procedures  for  avoiding  these  difficulties  and 
has  been  adapted  for  ICDT  as  described  in  the  following  discussion. 

The  allocation  of  hardware  and  software  data  processing  functions  in  this 
approach  is  based  on  the  flow  of  control  of  processing  rather  than  on  the 
flow  of  data  manipulated  by  the  processing.  This  has  been  found  to  be 
effective  for  avionics  systems  because  there  the  control  structures  generally 
are  complicated,  but  the  data  structures  are  elementary.  The  interface 
between  the  hardware  and  software  is,  in  this  case,  more  naturally  defined  in 
terms  of  the  control  of  the  processing.  The  description  of  the  data  flow  is 
done  later. 

30 

E.  R.  Rang,  "The  Use  of  Finite  State  Machines  for  Describing  and 

Validating  Flight  Control  Systems,  "  NAECON  r80  Dayton,  Ohio,  May  1980, 

Vol.  1.  pp.  347-353. 
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The  control  of  the  processing  is  described  in  terms  of  the  states  and 
substates  of  the  system  and  the  events  that  cause  transitions  in  these 
states  and  substates.  This  description  is  done  at  two  levels.  First,  an 
abstract  description  of  the  flow  of  control  is  made  without  reference  to 
hardware  or  software.  After  all  of  the  events  and  states  of  the  integrated 
data  processing  iunctions  have  been  defined,  the  control  of  flow  that  is  to 
be  done  by  software  functions  is  specified  to  complement  the  selected  hard¬ 
ware  facilities.  This  procedure  gives  a  precise  description  of  how  the 
software  must  control  the  processing  of  the  data.  Now  the  specification 
of  the  actual  computations  can  be  fitted  in  smoothly. 

This  approach  for  the  design  of  avionic  data  processing  facilities  is  practical 
since  the  required  computations  are  relatively  straightforward.  There  is 
not  a  complicated  sharing  of  resources  nor  are  there  elaborate  collections 
of  expanding  and  contracting  data  that  are  often  required  in  general  data 
processing  systems.  The  control  and  interrupt  structures  for  avionics 
are  not  complicated.  Usually  a  simple  executive  routine  calls  functions  in  a 
fixed  periodic  fashion.  The  control  structure  that  is  described  by  states 
and  outside  events  manipulates  the  functions  within  that  periodic  executive. 
The  approach  is  formalized  and  reviewed  in  greater  detail  and  an  example 
is  provided  in  the  following  discussion. 


3.4.  3.2.1  The  Finite  State  Formulation — A  finite  state  machine  is  a 
device  with  a  fixed  finite  set  of  internal  storage  elements  whose  states 
determine  the  state  of  the  machine.  When  an  input  is  received,  the  machine 
switches  to  a  new  state.  The  new  state  depends  on  the  previous  state  of  the 
machine  and  the  particular  input  that  was  received.  While  any  practical 
computing  device  has  only  a  finite  number  of  states,  the  concept  has  utility 
for  detailed  description  only  if  the  number  of  states  is  small.  Fortunately, 
the  data  processing  for  avionics  systems  may  be  defined  in  terms  of  a  small 
number  of  configurations.  A  formalization  of  this  approach  will  be  outlined 
by  modifying  the  discussion  in  Reference  34. 

1.  Define  the  External  Interface--An  abstract  machine  or  set  of  abstract 
machines  that  interact  with  the  non-data  processing  part  of  the  system 
and  the  controlling  factors  external  to  the  data  processing  subsystem 
are  defined.  These  are  specified  at  the  highest  level  by  suppressing 
as  much  detail  as  possible.  They  are  defined  by  listing  all  possible 
states  of  each  machine  and  by  listing  all  the  external  events  that  can 
make  a  change  in  the  states.  Tables  giving  the  state  changes  caused 
by  particular  events  are  convenient  means  for  representing  these 
abstract  finite  state  machines. 

2.  Define  the  System  Structure--The  next  stage  is  to  begin  constructing 
a  hierarchy  of  abstract  machines,  adding  detail  and  design  decisions. 
The  split  between  software  and  hardware  functions  is  now  defined 

by  finite  state  software  machines  interfacing  with  hardware  items. 


34 

L.  Robinson,  The  HDM  Handbook,  Vol.  I:  The  Foundations  of  HDM, 
SRI-International  Report  on  SRI  Project  4828,  Menlo  Park,  California, 
June  1979. 
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This  defines  in  more  detail  how  the  states  of  the  top-level  machine 
are  represented  and  how  the  events  are  defined  and  processed  to 
cause  the  correct  changes  of  state.  It  should  be  possible  to  formally 
verify  that  the  resulting  software  and  hardware  correctly  implement 
the  top-level  machine.  The  machines  are  still  abstract  in  that  no 
software  implementation  has  been  specified.  Some  items  of  hardware 
may  have  been  chosen. 

3.  Complete  the  hierarchy  of  abstract  machines--Now  more  detail  is 
added  to  complete  the  functionality  of  the  requirements  by  adding  new 
layers  of  machines.  These  introduce  substates  or  partitions  of  the 
top-level  states.  Some  iteration  back  to  stage  2  may  be  required. 

For  avionics  software,  only  two  levels  of  machines  have  been  found 
to  be  useful:  the  abstract  system  machine  and  its  corresponding 
software  component.  Other  machines  for  flight  control  modes, 
redundancy  management,  and  such  are  used,  but  these  are  completely 
and  directly  implemented  in  software;  no  hierarchical  representation 
has  been  found  to  be  useful. 

4.  Define  data  flow--For  the  most  part,  stages  1  to  3  have  been  concerned 
with  representing  an  appropriate  control  structure  to  make  the  resources 
of  the  system  available  when  called  by  the  events.  In  this  stage,  the 
details  of  the  computations  and  the  data  are  added.  If  everything  has 
gone  according  to  plan,  the  original  requirements  have  been  captured 

in  complete  detail.  At  this  point  a  review  of  the  whole  system  is  made 
before  design  of  the  software  begins. 
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5.  Estimate  performance  and  computer  requirements- -If  the  requirements 

are  organized  by  the  preceding  stages,  then  the  estimates,  the  detailed 

software  design,  and  the  coding  will  be  done  smoothly  and  reliably. 

The  integrated  control  methodology  ends  with  these  estimates. 

Each  of  the  subsystems  of  flight  control,  navigation,  weapon  delivery, 
and  effectiveness  management  will  have  a  description  of  its  states  and  the 
events  that  cause  changes  of  states.  These  have  been  established  from  the 
earlier  steps  of  ICDT. 

3. 4. 3.2.2  Illustrative  Application  to  Flight  Controls- -The  illustrative 
example  is  about  a  hypothetical  flight  controller  which  is  to  provide  commands 
for  stability  augmentation,  pilot  relief  modes,  and  commands  for  the  flight 
director  bars.  The  modes  in  the  pitch  axis  are  to  be: 

•  pitch  attitude  hold 

•  go- around 

•  altitude  hold 

•  glideslope 

•  control  wheel  steering 
and  for  the  roll  axis: 

•  wings  level 

•  heading  hold 

•  navigation 

•  approach 
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The  yaw  axis  will  get  only  a  damping  signal.  The  sensors  are: 

•  yaw  rate  gyro 

•  vertical  gyro 

•  compass 

•  altimeter 

•  VOR/LOC  receiver 

•  glideslope  receiver 

Switches  control  the  autopilot,  the  flight  director  engagements,  and  the 
modes  and  there  are  mechanical  means  for  slewing  the  heading  hold 
reference  and  for  adjusting  the  altitude  reference  value.  A  switch  is 
provided  for  disconnecting  the  system  in  emergency,  another  for  initiating 
the  go-around  mode,  and  a  third  for  engaging  the  control  wheel  steering 
mode.  A  basic  requirement  is  that  the  autopilot  can  be  engaged  only  if 
and  when  the  flight  director  has  been  previously  engaged. 

We  must  now  make  these  requirements  more  precise  by  adding  details 
and  design  decisions  when  appropriate.  The  top-level  abstract  machine 
is  defined  by  the  engagements  of  the  flight  director  and  the  autopilot. 

Thus,  the  states  are: 

0.  flight  director  off,  autopilot  off 

1.  flight  director  on,  autopilot  off 

2.  flight  director  on,  autopilot  on 

3.  flight  director  on,  autopilot  on, 
control  wheel  steering  on 


In  the  control  wheel  steering  mode,  the  servos  are  temporarily  disengaged 
while  the  pilot  maneuvers  to  a  new  pitch  attitude,  which  is  then  held 
automatically  when  the  switch  is  released.  The  events  that  can  alter  these 
states  are  caused  by: 

•  the  autopilot  dump  switch 

•  the  control  wheel  switch 

•  the  go- around  switch 

•  the  flight  director  switch 

•  the  autopilot  switch 

•  the  vertical  gyro  invalid  signal 

The  top-level  abstract  machine  is  then  defined  by  its  state  transition  table. 
Table  22.  The  entries  in  the  table  show  the  number  of  the  state  to  which 
the  present  state  is  switched  for  the  particular  event.  In  drawing  this 
table,  we  are  adding  detail  to  the  requirements.  For  example,  the  go-around 
switch  and  the  control  wheel  switch  are  to  turn  the  flight  director  on  if  it 
is  off. 

Nothing  has  been  specified  about  how  the  states  are  represented.  The 
relation  that  the  autopilot  can  be  turned  on  only  if  the  flight  director  is 
already  on  can  be  enforced  by  hardware  (a  mechanical  linking  of  switches, 
for  example)  or  by  software.  Some  ambiguities  must  be  cleared  up. 

For  example,  when  the  go-around  switch  turns  the  flight  director  on,  the 
system  must  know  that  the  flight  director  switch  has  also  been  turned  on. 


TABLE  22.  SYSTEM  FINITE  STATE  MACHINE 


Now  to  make  the  hardware /software  split  in  this  simple  system:  Assume 
that  the  flight  director  switch  is  a  momentary  contact  switch  which  gives 
a  signal  only  when  it  is  held  in.  Then  the  software  must  include  a  tiny 
finite  state  machine  to  record  the  status  of  the  pilot's  actions.  Assume 
that  this  is  also  true  for  the  autopilot  switch.  The  software  will  also 
enforce  the  state  definitions.  With  these  decisions,  the  finite  state  machine 
that  the  soft  wav  e  must  implement  is  represented  by  Table  23.  There  is 
not  much  change  from  Table  22  because  most  things  have  been  put  into 
softwa:,^  ,  If  'he  switches  had  been  mechanically  linked,  then  the  events  would 
not  be  it 1  pendent  and  Table  2  3  would  reflect  this. 

Nothing  has  yet  been  specified  for  the  signals  that  are  to  be  computed  when 
the  system  is  in  each  of  the  four  top-level  states.  That  comes  on  the  next 
level  of  hierarchy.  The  modes  that  are  engaged  are  controlled  by  the  pitch 
axis  logic  machine  and  the  roll  axis  logic  machine.  The  hierarchy  is 
illustrated  in  Figure  22.  There  will  be  further  hardware /software  decisions 
when  details  are  added;  they  have  minor  impact  on  the  system  structure. 

3. 4. 3. 3  Data  Processing  Hardware  Selection--It  is  now  an  easy  task  to  use 
a  capability  data  base  on  computers  and  peripheral  hardware  to  help  match 
the  requirements  on  throughput,  memory,  and  so  on.  This  will  provide 
a  facsimile  of  the  system  from  which  size,  weight,  power,  cost,  and 
reliability  of  the  data  processing  hardware  may  be  estimated. 


TABLE  23.  TOP-LEVEL  SOFTWARE  SYSTEM  MACHINE 
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Figure  22.  Hierarchy  of  Machines 

3. 4. 3.  4  Software  Design- -Most  avionic  software,  particularly  that  used 
for  flight  controls,  is  not  complicated.  It  is  composed  of  a  large  number 
of  simple  functions,  and  the  data  structures  are  elementary.  There  are 
fixed  sets  of  inputs,  outputs,  and  state  variables.  The  control  of  flow 
structure  is  direct  with  no  complicated  while-do  loops.  Few  constructs  of 
the  complexity  found  in  general  software  systems  are  necessary.  This 
basic  simplicity  allows  a  methodology  for  specification  and  design  that  will 
facilitate  the  subsequent  coding  and  verification. 
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The  traditional  approach  has  focused  on  the  code  itself,  usually  done  in 
assembly  language.  Some  attention  was  paid  to  top-down  structure  but 
not  in  any  serious  way.  The  simplicity  of  the  problem  permitted  this 
approach.  Even  so,  it  has  been  found  that  more  attention  to  specification 
and  design  pays  dividends  in  verification,  validation,  and  maintainability, 
thus  saving  considerably  in  life-cycle  costs.  While  the  ICDT  methodology 
stops  with  preliminary  design,  that  stage  must  be  in  a  form  which  permits 
the  detailed  design  to  resume  without  much  backtracking  through  the  entire 
design  process.  Many  new  approaches  are  needed  to  software  development. 
The  first  need  is  to  incorporate  the  use  of  a  programming  language  at  a  higher 
level  than  assembly  language.  The  second  need  is  to  have  the  description 
of  the  specifications  in  a  more  precise  form  than  the  format  provided  for 
in  part  1  of  the  design  specifications.  This  precision  is  necessary  to  allow 
verification  and  validation  to  be  made  against  a  definite  statement  of  the 
system  requirement.  While  part  1  of  the  design  specifications  does  well 
in  describing  for  individual  functions,  it  does  not  give  a  comprehensive 
picture  of  the  global  structure  of  the  system  that  is  sufficient  for  validation. 

Our  approach  to  the  flight  control  software  design  builds  on  the  finite  state 
machine  specifications  described  in  an  earlier  subsection.  This  approach 
provides  the  global  structure  which  is  captured,  along  with  the  functional 
requirements,  by  pseudo  code  in  a  hierarchy-input-process-output  (HIPO) 
format.  The  consistency  of  the  input- output  relations  of  the  HIPO  modules 
can  be  verified  by  hand  or  by  formal  machine  procedures.  Subsequent 
coding  will  proceed  from  the  HIPO  charts  in  high  level  language  or  assembly 
language,  whichever  is  called  for  in  the  project.  This  is  not  part  of  the 
preliminary  design  methodology;  we  add  this  to  show  how  the  verification 
cycle  may  be  completed. 
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The  code  may  be  verified  against  the  HIPO  charts,  which  in  turn  may  be 
verified  against  the  finite  state  machine  description.  This  structure  is 
highly  visible;  it  is  checked  by  review.  The  verification  procedures  can 
be  made  more  explicit  for  special  structures.  For  example,  for  flight 
controls  the  following  groups  of  requirements  must  be  established: 

•  The  transitions  and  outputs  of  the  system  mode  logic  machines 
are  correct. 

•  The  computations  of  the  control  laws  for  each  mode  are  correct. 

•  The  data  is  correctly  initialized  and  the  state  variables  are 
preserved  to  the  next  computational  cycle. 

•  The  rate  executive  structure  of  calling  the  software  modules 
for  computation  is  correct. 

•  The  data  transfer  between  software  modules  is  correct. 

Considerations  of  verification  and  validation  are  central  in  a  software 
methodology  just  as  provisions  for  testing  are  central  considerations  in 
designing  very  large  digital  hardware  configurations. 

3. 4. 3.  5  Estimation  of  Effectiveness  of  the  Data  Processing  Hardware 
and  Software-Hardware  effectiveness  may  be  estimated  for  the  facsimile 
system  chosen  in  subsection  3.4.3. 3.  An  estimate  of  the  reliability  and 
maintainability  may  be  made  from  data  on  previous  systems  using  similar 
hardware.  The  performance  may  be  reverified  with  the  more  detailed 
software/hardware  configuration  produced  in  the  subsequent  design  efforts. 


Software  should  be  designed  and  verified  to  be  correct.  Since  avionic 
software  does  not  have  the  involved  data  and  control  structures  of  general 
software,  this  is  not  an  unreasonable  requirement.  Data  and  control 
structures  of  avionic  software  should  not  have  complicated  interrupt  levels. 
The  software  methodology  should  guarantee  correctness.  The  newer 
methodologies  make  changes  easier  and  more  secure;  this  enhances 
maintainability  and  reduces  life- cycle  costs. 

3.4.4  Subsystems  Interfacing  Design 

At  this  point  in  the  implementation  part  of  the  design  methodology,  the 
components  for  the  non-data  processing  and  the  data  processing  subsystem 
have  been  selected.  These  components  implement  one  or  more  functionally 
defined  COF  system  candidate  configurations.  The  software  development 
has  been  carried  through  its  preliminary  design  stage.  Nothing  has  been 
done,  however,  about  specifying  the  interfacing  design  that  enables  the 
subsystems  and  components  to  communicate  with  each  other  and  to  be 
controlled. 

The  selection  of  the  components  has  been  based  primarily  on  how  well  they 
meet  the  performance  (capability)  requirements  that  have  been  decomposed 
from  the  mission/system  level  to  the  component  level.  As  far  as  the 
reliability,  maintainability,  and  survivability  attributes  have  been  considered, 
the  selection  of  components  has  been  based  only  on  having  maximum  values 
of  these  characteristics  once  the  performance  requirements  are  satisfied. 

No  prior  decomposition  of  the  values  of  these  three  attributes  to  the 
component  level  has  been  done  to  set  minimum  goals. 
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The  objective  of  the  interfacing  design  process,  therefore,  is  not  only  to 
provide  a  communication  link  between  the  subsystems  and  components  l  ut 
also  to  upgrade  the  reliability,  maintainability,  and  survivability  of  the 
integrated  system  by  incorporating  redundancy,  reconfigurability,  and 
survivability  measures  if  and  where  necessary  to  meet  the  system  level 
goals.  This  process  is  illustrated  in  Figure  23.  The  substeps  within 
the  implementation  step  of  the  design  process  are  significant  because 
they  must  ensure  meeting  three  of  the  four  attribute  goals  that  combine 
to  establish  the  system  effectiveness  goal.  Performance,  the  fourth 
attribute,  has  been  designed  in  at  its  required  level  during  the  functional 
design  and  the  selection  of  components  and  it  is  assumed  that  the  system's 
performance  will  not  be  degraded  by  the  interfacing  design.  A  failure  that 
cannot  be  compensated  for  may  occur,  however,  and  cause  the  system 
to  perform  in  a  degraded  operability  state. 

It  should  be  noted  that  the  interfacing  design  alsc  provide*  0;e  third 
opportunity  for  enhancing  the  integrated  control  design  aspects  of  the  system. 
The  first  opportunity  occurs  during  the  functional  design  when  examinations 
can  be  made  and  judgments  can  be  applied  to  reduce  functional  redundancy. 
The  second  opportunity  occurs  during  the  component  selection  when  the 
availability  and  applicability  of  multifunction  components  (hardware  and 
software)  can  be  considered.  This  third  opportunity  is  the  application  of 
integration  considerations  during  the  interfacing  design  in  order  to  minimize 
the  hardware  and  software  necessary  for  the  interfacing  implementation. 


107 


Figure  23.  Expanded  View  of  Subsystems  Interfacing  Design  (Substep  3i) 


Since  the  interfacing  design  substep  is  started  with  only  the  functional  and 
decomposed  performance  requirements  met  and  with  the  components 
selected  primarily  on  the  basis  of  performance,  an  iterative  process  will 
usually  be  required  during  the  interfacing  design  to  reach  the  system 
effectiveness  goals.  The  first  substep  of  the  iterative  process  is  to  assume 
that  the  functional  design  and  component  selections  that  are  the  outputs  of 
Step  2  and  substeps  3e  and  3h,  respectively,  are  integrated  only  by  a 
single- thread  interfacing  design  plus  a  simple  baseline  maintenance  plan 
and  then  to  evaluate  the  reliability,  maintainability,  and  survivability 
of  this  simple  single- thread  system.  These  values  can  be  combined  with 
performance  values  to  get  a  system  effectivensss  estimate.  If  the  evaluated 
effectiveness  meets  the  mission/system  level  goal,  which  is  not  likely, 
the  design  is  complete.  If  the  effectiveness  goal  is  not  met,  then  the 
values  achieved  for  reliability,  maintainability,  and  survivability  must 
be  inspected  and  an  analysis  performed  to  see  where  and  why  the  goals 
for  these  attributes  were  not  met.  This  introspective  analysis  then  provides 
the  basis  for  the  second  substep  in  the  interfacing  design,  which  will 
incorporate  whatever  reliability,  maintainability,  and  survivability  measures 
(redundancy,  reconfigurability,  shielding,  relocation,  etc.)  are  expected  to 
be  necessary  to  meet  the  attribute's  goals.  This  second  substep  will 
involve  a  significant  trade-off  study  because  the  design  parameters  used 
to  improve  reliability  and  survivability  will  probably  reduce  maintainability, 
and  a  careful  adjustment  of  the  parameters  will  likely  be  necessary  to 
meet  all  three  goals  simultaneously.  Thus,  it  is  highly  likely  that  an 


iteration  of  the  interfacing  design  will  be  required  to  meet  the  system-level 
effectiveness  goal.  When  the  life- cycle  cost  (LCC)  of  the  candidate  system 
is  subsequently  evaluated,  it  may  exceed  the  LCC  goal  and  cause  an 
additional  iteration  in  either  the  component  selection  or  the  interfacing 
design  substeps. 

Brief  descriptions  of  the  tools  and  processes  required  to  carry  out  the 
reliability,  maintainability,  and  survivability  evaluations  and  design 
upgrading  are  presented  in  the  following  subsections. 

3.  4.  4. 1  Reliability  Evaluation  and  Design- -The  reliability  evaluation  tool 
recommended  for  the  ICDT  methodology  is  the  System  Effectiveness  State 
Diagram  Interpretive  Program  (SESIP)  analytical  model  and  program 
employing  Markov  modeling  techniques  which  was  developed  by  Honeywell. 
This  is  described  in  more  detail  in  Reference  35  and  in  subsection  3.  5. 

It  is  an  efficient  tool  well  suited  to  the  concept  definition  level  of  COF 
system  design. 


35 

J.  Pukite,  "System  Effectiveness  Modeling,  "  presented  at  Computer  Aids 
to  System  Effectiveness  Institute,  Milwaukee,  Wisconsin,  20  May  1968. 
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The  approach  to  designing  additional  reliability  into  the  components  and  the 
interfacing  subsystem  has  been  selected  to  fit  the  ICDT  design  level;  it 
is  described  in  the  following  paragraph. 

A  reliability  state  model  of  the  single- thread  system  is  generated  during 
the  application  of  the  SESIP  tool  to  evaluate  the  system's  reliability  and 
dependability.  With  this  state  diagram,  the  primary  sources  of  unreliability, 
or  the  areas  of  the  single- thread  system  design  where  reliability  can  best 
be  enhanced,  can  be  identified.  Then  various  redundancy  techniques  to 
make  the  system  more  fault  tolerant  must  be  considered  and  applied.  These 
redundancy  techniques  can  be  applied  either  to  the  components  selected 
or  to  the  communication  links  that  provide  the  interfacing  of  the  single- thread 
system.  The  three  main  categories  of  redundancy  techniques  are  static, 
dynamic,  and  hybrid.  A  description  of  these  techniques  and  how  they  may 
be  applied  to  improve  reliability  through  fault  tolerance  is  given  in  Reference 
36. 
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'A.  Avizienis,  "Fault  Tolerant  Systems,  "  IEEE  Transactions  on  Computers, 
Vol.  C-25,  No.  12,  December  1976. 
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3. 4. 4.2  Maintainability  Evaluation  and  Design- -The  technique  for  designing 
more  maintainability  into  the  system  and  for  improving  its  availability  is 
a  two-step  procedure.  First,  the  components  selected  and  the  existing 
interfacing  implementation  are  reconsidered  for  adjustments  that  will 
minimize  mean  time  for  detecting  and  repairing  faults  or  failures.  These 
adjustments  could  take  the  form  of  increasing  component  reliability  or 
improving  BITE.  Then  the  maintenance  plan  can  be  adjusted  to  get  a 
further  increase  in  the  availability  attribute.  These  reconsiderations  and 
adjustments  are  made  using  the  system  state  diagrams.  They  must  then 
be  evaluated  against  the  availability  goal  and  repeated  if  the  goal  has  not 
been  reached.  Section  3.5  provides  models  of  maintenance  plans  that 
can  be  used  to  compute  the  availability  of  a  system  as  well  as  its  maintainability. 

3. 4. 4.  3  Survivability  Evaluation  and  Design — The  survivability  evaluation 
tool  recommended  for  the  ICDT  methodology  is  the  survivable  digital  control 
(SUDIC)  Quick  Analysis  model  developed  by  Honeywell  for  the  Navy  (see 
Reference  37).  It  is  described  in  more  detail  in  subsection  3.5.  It 
provides  an  evaluation  of  system  survivability  in  the  face  of  hostile  action 

3 

that  includes  small  A  weapons.  It  can  be  extended  to  include  other  weapons 
by  expanding  its  weaponry  data  base. 
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K.  D.  Graham,  T.B.  Cunningham,  and  Charles  Shure,  Aircraft  Flight 
Control  Survivability  Through  Use  of  On-Board  Digital  Computers: 

A  Design  Guide,  Vol.  1,  NADC-77028-30,  Washington,  D.C. :  Naval 
Air  Systems  Command,  May  1980. 


The  approach  recommended  for  designing  survivability  into  a  system  is 
described  below.  This  approach  encompasses  the  use  of  redundancy, 
reconfiguration,  relocation,  and  shielding  as  techniques  for  improving 
survivability.  The  reconfiguration  aspect  of  the  survivability  design  is 
also  an  integral  part  of  the  implementation  design  for  the  effectiveness 
management  function  described  in  subsection  3. 2. 2. 2. 4. 

With  the  partially  interfaced  system  design  resulting  from  the  incorporation 
of  reliability  and  maintainability  measures  into  the  single- thread  system, 
the  first  step  taken  in  the  survivability  design  is  dispersion  of  the  system's 
components.  The  approaches  to  effective  dispersion  and  the  ways  of 
estimating  the  resulting  increments  to  the  system  survivability  are  described 
in  the  SUDIC  report. 

The  next  survivability  measure  to  be  considered  is  the  incorporation  of 
system  reconfigurability  techniques.  A  detailed  description  of  an  approach 
to  designing  reconfigurability  into  a  flight  control  system  is  also  described 
in  Reference  37.  This  approach  is  applicable  to  COF  systems  as  well  as 
to  flight  control  subsystems  and  is  recommended  for  ICDT.  Basically  the 
COF  system  reconfiguration  is  accomplished  through  identification  of  faults 
or  damage  within  the  system  and  the  application  of  effectiveness  management 
logic  to  switch  functions  (wholly  or  partially)  to  undamaged  components  and 
to  reconfigure  flight  control  functions,  if  necessary. 
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The  fault  or  damage  detection  and  isolation  aspects  of  reconfigurability 
design  are  much  the  same  as  those  for  reliability  design.  The  reconfigurability 
design,  however,  permits  recovery  from  the  fault  or  damage  by  switching 
functions  to  undamaged  components  that  are  not  redundant.  Those  components, 
which  perform  other  functions,  can  be  used  as  backup  components.  The 
backup  components  restore  part  or  all  of  the  function  lost  because  of  the 
failure  or  damage.  Reconfiguration  decision  criteria  are  needed  for 
developing  the  switching  (effectiveness  management)  logic  and  for  modifying 
the  flight  control  laws,  if  necessary.  The  methods  for  developing  these 
criteria  are  described  in  Reference  37.  Once  the  criteria  are  selected,  the 
effectiveness  management  logic  for  switching  the  functions  can  be  derived 
and  used  in  the  functional  design  of  the  effectiveness  management  system 
(see  subsection  3.3.2.  5). 

The  next  survivability  measure  to  be  considered*  if  the  dispersion  and 
reconfigurability  design  steps  do  not  provide  an  increment  sufficient  to 
meet  the  COF  system  survivability  goal,  is  the  protection  of  components 
by  shielding  or  hardening  and  the  clustering  of  components  as  described 
in  Reference  37. 

If  survivability  is  still  lacking  after  the  increments  from  all  these  techniques 
have  been  evaluated,  an  iteration  of  the  redundancy  design  for  reliability 
and/or  of  the  various  approaches  to  survivability  design  must  be  undertaken. 
The  order  in  which  these  approaches  are  iterated  should  be  selected  by  the 
system  designer  on  the  basis  of  their  relative  effectiveness  as  noted  during 
their  first  applications. 


3.4.5  LCC  Ebdmation  Techniques 

In  order  for  the  LCC  estimation  technique  for  ICDT  to  be  consistent  with 
the  concept  definition  level  of  system  design,  it  must  be  an  efficient  process 
and  dependent  only  on  those  performance  and  design  parameters  that  are 
quantified  during  concept  definition. 

To  achieve  an  efficiency  compatible  with  the  rest  of  the  ICDT  techniques,  a 
parametric  LCC  estimation  technique  is  called  for.  (See  References  38,  39, 
40.)  The  parametric  approach  is  one  of  four  LCC  estimation  approaches 
identified  in  a  current  survey  paper  in  Reference  38.  These  were: 

•  Parametric  approach 

•  Analogy 

•  Engineering  (build  up)  or  accounting  models 

•  Historical  data 
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Richard  W.  Grim,  "Financial  Management  of  Avionics  and  Electronic 
Systems,  "  Presented  at  NAECON  '80,  Dayton,  Ohio,  May  1980. 
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E.  Louis  Wienecke,  III,  Erasmus  E.  Feltus,  and  Daniel  V.  Ferens, 

"The  Avionics  Laboratory  Predictive  Operations  and  Supports  (ALPOS) 
Cost  Model,  "  Presented  at  NAECON  '80,  Dayton,  Ohio,  May  1980. 

40Edward  N.  Dodson,  "Life-Cycle  Cost  Analysis:  Concepts  and  Procedures, 
AGARD  Lecture  Series  No.  100  (Methodology  for  Control  of  Life- Cycle 
Costs  for  Avionic  Systems),  1979. 
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The  parametric  approach  requires  cost  estimating  relationships  (CERs)  to 
make  it  predictive.  CERs  relate  the  dependent  variables,  which  are  the 
life-cycle  cost  elements,  to  the  independent  variables,  which  are  the 
system  design,  production,  and  maintenance  parameters.  In  Reference  38, 
the  use  of  parametric  techniques  was  identified  as  the  best  approach  for 
making  cost  effectiveness  trade-off  studies  early  in  a  system  development 
program.  Reference  39  states  that  "early  visibility  of  potentially  excessive 
downstream"  costs  is  required  since  investigations  have  shown  that  as 
much  as  seventy  percent  of  the  system  LCC  is  determined  by  the  end  of 
concept  definition  studies  as  depicted  in  Figure  24. 


CONCEPT  CONCEPT  DEVELOPMENT  PRODUCTION  OPERATIONS 

FORMULATION  VALIDATION 


PROGRAM  TIME  PHASE 


Figure  24.  Percentage  of  System  LCC  vs.  Program  Time 
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Appreciation  of  this  fact  suggests  that  parametric  techniques  to  predict 
LCC  should  be  available  in  the  conceptual  phase.  The  following  subsections 
describe  a  parametric  LCC  estimation  technique  that  will  fit  the  ICDT 
level  of  design  methodology  and  will  accommodate  the  early  application 
objectives.  The  full  implementation  of  this  technique  requires  development 
of  the  CERs.  This  development  is  one  of  the  future  objectives  of  the  ICDT 
program. 

3.4.5. 1  Technique  Development- -An  LCC  parametric  estimation  technique 
tailor  i  to  ICDT  was  developed  because  the  existing  techniques  reviewed 
were  not  completely  satisfactory.  Recognizing  that  a  system  is  almost 
always  treated  as  two  distinct  subsystems,  hardware  and  software,  during 
the  design  and  LCC  estimating  exercises  and  that  the  first  level  of  cost 
decomposition  is  acquisition  costs  and  operation  and  support  costs,  LCC 
techniques  are  usually  classified  as  shown  in  Table  24  from  Reference  38. 

The  table  also  contains  the  names  of  some  of  the  existing  predictive  techniques. 

TABLE  24.  EXISTING  PREDICTIVE  LCC  ESTIMATION  TECHNIQUES 


Acquisition  Costs 

Operation  and  Support 
Costs 

Hardware 

PRICE  H 

PRICE  L 

ALPOS 

Save 

Software 

PRICE  S 

Slim 

W  olverton 

Aerospace  Model 

Boeing  CLMM 

GRC  Model 

F-16  Model 

i 
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The  techniques  listed  above  are  useful  but,  in  general,  represent  either 
an  overly  complicated  or  overly  simplified  LCC  estimation  process  for  the 
concept  level  definition  of  design. 

The  following  derivation  of  an  LCC  estimation  formula  for  ICDT  is  aimed 
at  identifying  an  appropriate  set  of  cost  categories  and  cost  parameters  to 
cover  design,  production,  and  maintenance.  The  preliminary  relationships 
between  these  cost  categories  and  parameters  are  derived  from  and  can  be 
finalized  by  developing  the  CERs  indicated.  These  CERs  will  be  appropriate 
for  doing  cost  vs  design  characteristics  trade-offs  at  the  concept  definition 
level. 


The  first  decomposition  of  LCC  for  ICDT  is  the  practical  and  traditional 
split  between  hardware  and  software  costs: 

lccicsys  "  LCCHDWE  +  LCCSFWE  (1) 

Next,  the  cost  elements  that  make  up  a  system  LCC  are  considered.  The 
most  appropriate  first  level  of  decomposition  is: 

LCC  =  AQC  +  OSC  (2) 

where, 

AQC  =  system  acquisition  costs  (not  including  spare  or  support 
equipment) 

OSC  =  operating  and  support  costs 
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The  life  cycle  cost  for  ICDT  can  now  be  expressed  as: 


LCC 


ICSYS 


=  AQC 
+  AQC 


HDWE 

SFWE 


+  CSC 


HDWE 


+  CSC 


SFWE 


(3) 


One  further  level  of  decomposition  of  these  costs  categories  is  necessary 
before  they  can  be  functionally  related  to  the  significant  design,  production, 
and  maintenance  parameters.  These  relationships  identify  the  CERs  that 
will  have  to  be  established  to  provide  the  concept  definition  level  of  LCC 
estimation  methodology. 

For  hardware  costs  it  is  appropriate  and  has  been  traditional  to  break 
acquisition  costs  into  these  categories: 

aqchdwe  ”  RDC  +  pc 

where,  RDC  =  research  and  development  costs  (for  the  system) 

PC  =  production  costs  of  the  initial  number  of  operational 
units  (10V)  procured 

and  to  break  the  hardware  operating  and  support  cost  into  these  categories: 

OSC^™^  =  TRLC  +  SC  +  DREC  +  OSOC 
HDWE 

where,  TRLC  =  test  and  repair  labor  costs 
SC  =  spares  costs 

DREC  =  dedicated  repair  equipment  costs 
OSOC  =  operating  and  support  overhead  costs 
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The  software  acquisition  costs  (often  referred  to  as  software  development 
costs  in  the  literature)  can  be  broken  into  categories  that  correspond  to 
the  phases  of  development  as  follows: 

AQCcl?u,p  =  RAC  +  FDC  +  DDC  +  VVC 

or  W  XL 

where, 

RAC  =  requirements  analysis  costs 

FDC  =  functional  design  costs 

DDC  =  detailed  design  costs 

VVC  =  validation  and  verification  costs 

The  software  operating  and  support  (O&S)  costs  are  the  least  well  known 
and  understood.  The  breakdown  into  categories  corresponding  to  phases 
of  O&S,  however,  will  be  assumed  as: 

OSCgFWE  =  FTC  +  REDC  +  RVVC 

where,  FTC  =  field  test  cost 
REDC  =  redesign  costs 
RVVC  =  revalidation  and  verification  costs 

Nov  chat  all  the  cost  components  or  dependent  variables  to  be  used  in  a 
concept  definition  LCC  methodology  have  been  identified,  the  independent 
variables  to  be  used  in  the  CERs  must  be  identified.  One  problem  with  the 
dependent  variable  identification  is,  of  course,  that  there  sure  so  many. 
Consequently,  only  the  top-level  variables,  that  is,  those  parameters  that 
drive  the  costs  significantly,  are  desired  for  concept  definition  work. 
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The  cost  drivers  can  be  put  into  three  groups  for  best  association  with  the 
LCC  cost  categories.  These  groups  are: 

•  Driving  design  parameters  (DDP) 

•  Driving  production  parameters  (DPP) 

•  Driving  O&S  parameters  (DOSP) 

Experience  has  shown  that  their  primary  influence,  the  top-level  LCC  cost 
categories,  can  be  identified  as  follows: 


aqchdwe 

=  f(DDP,  DPP) 

OSCHDWE 

=  f(DOSP,  DDP,  DPP) 

aqcsfwe 

=  f(DDP) 

OSCSFWE 

=  f(DDP,  DOSP) 

Many  studies  for  developing  CERs  have  identified  the  driv<ng  parameters  as 
follows: 


DDP 

•  Weight 

•  Size 

•  Type  (of  system) 

•  Technology 

•  Complexity 

•  System  Failure  Rates 
(MTBF) 


DPP 

•  Number  of  units 
initially  ordered 
(NUI) 

•  Cost  per  unit  of 
initial  order 
(CUI) 

•  Production  learning 
curve  (PLC) 


DOSP 

•  Maintenance  and 
replacement  policy 
(MRP) 

•  Spares  provisioning 
policy  (number  of 
initial  and  piplem 
spares  (SPP)) 

•  O&S  labor  rates 
(LR) 
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Number  of  line 
replaceable  units 
per  system  (NLRU) 

System  Repair  rates 
(MTTR) 

Operating  hours  per 
month  per  system 
(OHM) 

The  tasks  remaining  for  creation  of  the  CERs  are  to  identify  for  each 
dependent  variable  (the  LCC  cost  categories)  the  independent  variables 
(the  cost  parameters)  that  drive  them  significantly  and  to  derive  a  specific 
functional  relationship  between  them. 

For  the  ICDT  methodology  a  review  of  the  existing  parametric  LCC 
estimation  techniques  has  indicated  that  the  CERs  for  the  LCC  categories 
will  probably  involve  the  following  sets  of  driving  parameters: 

f(type,  technology,  complexity,  DEL) 

CUI  x  NUI  =  f  (weight,  size,  technology 
complexity,  PLC)  x  NUI 

=  f(MRP,  LR,  NLRU,  MTBF,  MTTR.  OHM) 

*  f(CUI,  PLC,  MRP,  SPP,  NLRU,  OHM) 

=  f(type,  technology,  complexity,  MTBF, 

MRP,  NLRU.  OHM) 


for  AQC 


HDWE 


RDC 

PC 


for  OSC 


HDWE 


TR  LC 
SC 
DR  EC 


•  Design  Experience  Level 
(DEL) 


OSDC  ■  f(MRP,  SPP,  LR.  NUI,  NLRU,  OHM) 


RAC  =  f(type,  complexity,  DEL) 

FDC  =  f(type,  technology,  complexity,  DEL) 

DDC  =  f(type,  technology,  complexity,  DEL) 

VVC  =  f(type,  complexity,  DEL) 

FTC  =  f(type,  complexity,  MRP) 

REDC  =  f(type,  technology,  complexity,  DEL,  MRP) 
RVVC  =  f(type,  complexity,  DEL,  MRP) 

These  functional  relationships  (CERs)  can  be,  and  to  some  extent  have  been, 
derived  by  collecting  significant  samples  of  cost  data  and  doing  a  regression 
analysis  of  it.  In  some  cases  CERs  from  other  studies  may  be  adopted  and 
adapted  to  the  ICDT  LCC  estimation  methodology,  particularly  in  the 
hardware  categories.  Two  other  options  exist.  The  first  of  these  is  to 
collect  the  cost  data  and  do  regression  analysis  to  derive  CERs  that  fit  the 
ICDT  concept  definition  level  of  LCC  estimation.  The  second  of  these  is 
to  adapt  the  ICDT  methodology  to  utilize  existing  methodologies. 

At  present,  any  interim  application  of  the  ICDT  methodology  as  developed 
(before  the  next  phases  of  ICDM  development  which  will  cover  data  collection 
and  implementation  of  the  methodology  flow)  must  depend  on  adopting 
existing  LCC  estimation  methodologies,  though  they  may  not  be  efficient 
with  respect  to  the  concept  definition  level  of  design  detail. 


for  AQC 


SFWE 


for  OSC 


SFWE 
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The  following  existing  and  nonproprietary  methodologies  are  adopted  for 
interim  use: 

Acquistion  Cost  Operation  and  Support  Cost 

Hardware  PRICE  H  PRICE  L  or  ALPOS* 

Software  PRICE  S  PRICE  S3*  or  Boeing  CLMM41 

One  further  reflection  on  the  development  of  an  ICDT- tailored  LCC  estimation 
methodology  is  worth  noting.  The  design  driving  parameter  referred  to  as 
complexity  has  many  facets.  It  may  be  necessary  to  develop  parameter 
estimation  relationships  (PERs)  that  relate  system  effectiveness  and 
performance  parameters  to  the  complexity  parameter  in  order  to  properly 
scale  the  complexity  of  a  system.  For  the  ICDT  methodology  a  breakdown 
of  the  anticipated  cost-relatable  (through  complexity)  performance  and 
effectiveness  parameters  for  the  ICOF  subsystems  used  in  this  study  are 
shown  in  Table  25.  Values  of  all  of  these  parameters  are  established  during 
a  system  design  at  the  concept  definition  level. 

3.  5  SYSTEM  EFFECTIVENESS  EVALUATION  PROCESS 

3.5.1  Summary  of  Results 

The  WSEIAC  methodology  with  modifications  to  include  estimation  of 
survivability  and  of  pilot  performance  provides  the  model  structure  re¬ 
quired  for  the  ICDT  effectiveness  evaluation.  The  modifications  include 


When  it  becomes  available 
41 

Daniel  V.  Ferens  and  Robert  L.  Harris,  "Avionics  Computer  Software 
Operation  and  Support  Cost  Estimation,  "  Presented  at  NAECON  *79, 
Dayton,  Ohio,  May  1979. 
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TABLE  25.  COST-RELATABLE  ICOF  SUBSYSTEM  PERFORMANCE 
AND  EFFECTIVENESS  PARAMETERS 


Capability 

Flirht  Control 

Dependability 

Availability 

Survivability 

•  Sensor  accuracy 

•  Stabilisation 

response  times 

•  Number  of  command 

modes 

•  Command  mode 

response  times 

•  Algorithms 

required 

•  MTBF 

•  Component 

redundancy 

•  MTBF 

•  MTTR 

•  BIT/FIT 

sophistication 

•  Component 

hardness 

•  Component 

shielding 

•  Component 

redundancy 

•  Component 

spacing 

•  Reconfigura¬ 

tion 

capability 

Navigation 

•  Sensor  accuracy 

•  Number  aiding  sensors 

•  CEP  performance 

•  Number  of  steering 

modes 

•  Type  of  modes 

•  Algorithms  required 

Same  parameters 
as  above 

Same  parameters 
as  above 

Same  parameters 
as  above 

Weapon  Control 

•  Sensor  accuracy 

•  Number  of  sensors 

•  Sensor  range 

•  Sensor  environmental 

capability 

•  Tracking  accuracy 

•  Release  time 

accuracy 

•  Algorithms  required 

Same  parameters 
as  above 

Same  parameters 
as  above 

Same  parameters 
as  above 

Effectiveness  Management 

•  Failure  test  points 

•  Redundancy  maintenance 

capability 

•  Number  of  algorithms 

•  Throughput  and  memory 

•  Reconfiguration  capability 

Same  parameters 
as  above 

Same  parameters 
as  above 

Same  parameters 
as  above 
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•  A  derivative  of  the  SUDIC  model  to  be  used  to  quantify 
survivability 

•  A  new  technique  required  to  evaluate  the  effects  of  man- 
machine  capability  (pilot  performance)  on  overall  system 
effectiveness 

•  Hardware /software  capability  (performance)  models  that  will 
be  unique  to  ICDT. 

Survivability  was  not  included  in  the  original  WSEIAC  methodology.  Experience 
has  shown  that  design  for  survivability  is  a  very  important  consideration 
that  can  have  an  impact  on  both  overall  system  performance  and  system  cost. 
Since  these  two  factors  provide  the  evaluation  impetus  for  the  ICDM, 
survivability  should  be  considered. 

The  same  rationale  also  applies  to  the  man-machine  design.  The  work 
completed  to  date  to  incorporate  pilot  performance  into  the  system 
effectiveness  (SE)  evaluation  process  was  found  to  be  either  too  cumbersome 
(pilot  work  load  estimation)  or  incomplete  (that  is,  performance  factor 
stated  in  the  SE  model  without  adequate  substantiation  of  the  performance 
number  defined).  Thus  the  model  required  additional  man- machine  con¬ 
sideration. 

The  third  point  above  refers  to  the  system  design  configuration  and  is 
unique  to  a  fully  integrated  control  design.  A  fully  integrated  design  by 
definition  will  share  components  to  implement  the  required  system  functions. 
Past  design  configurations  generally  have  each  system  function  implemented 
independently  of  the  other,  that  is,  the  navigation  subsystem  is  completely 
independent  of  the  flight  control  subsystem.  This  permits  system  effectiveness 


evaluation  at  the  subsystem  level  rather  than  at  the  component  level 
because  of  the  complete  correlation  of  a  particular  set  of  components  to 
a  system  function. 

On  the  other  hand,  in  a  fully  integrated  design  one  component,  such  as  a  gyro 
or  computer,  may  be  shared  by  two  system  functions  such  as  navigation 
and  flight  control.  The  effectiveness  evaluation  process,  therefore,  must 
carefully  consider  the  component /system  functional  relationship  in  establishing 
the  system  states  (that  is,  the  operational,  degraded,  and  failed  states  of 
the  system).  A  detailed  discussion  of  the  evaluation  process  recommended 
is  given  below. 

3.5.2  Model  Requirements 

Generic  system  effectiveness  evaluation  model  requirements  were  first 
defined  to  guide  the  model  definition  task: 

•  The  effectiveness  evaluation  process  shall  substantiate  the 
selected  design  on  the  basis  of  mission  performance. 

•  In  scope  and  level  of  detail  the  evaluation  process  shall  be 
consistent  with  the  data  available  during  the  concept  definition 
phase. 

•  The  evaluation  process  shall  be  applicable  to  a  digital  integrated 
control  system  design  methodology  and  to  new  aspects  of  system 
design  using  hardware  and  software  for: 

--reconfiguration  and  redundancy  management 

— fault  isolation 
--fault  tolerance. 


127 


•  The  evaluation  process  shall  provide  the  capability  to  identify 
areas  of  inadequacy  in  system  design  and  design/cost  drivers, 
such  as: 

--reliability 
-  -  maintainability 

--mission  effectiveness  (availability,  dependability,  survivability, 
capability). 

•  The  evaluation  process  shall  be  modeled  for  flexibility,  growth, 
and  expansion  (adding  flight  management  features). 

•  The  evaluation  process  shall  be  realistic  and  manageable  with 
respect  to  applying  it  at  the  concept  definition  level. 

A  general  procedure  and  modeling  tasks  to  meet  the  above  requirements 
are  summarized  below. 

•  A  procedure  shall  be  established  to  define  and  relate  the 
mission  goals  (selection  criteria)  to  the  system  design  parameters. 

•  Accordingly,  within  the  procedure  defined  above,  a  model  shall 
be  defined  that  relates  the  system  attributes  to  availability, 
dependability,  survivability,  and  capability  design  (man-hardware 
and  software)  and  to  logistic  system. 

•  A  modular  approach  shall  be  used  to  provide  program  flexibility 
and  growth. 

The  effectiveness  evaluation  procedure  and  a  model  that  satisfies  the  above 
requirements  is  defined  in  the  following  subsections. 
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3.5.3  Process  Flow /Steps 


As  stated  in  the  summary  of  results  above,  the  WSEIAC  methodology,  with 
the  recommended  modifications,  will  form  the  basis  for  the  evaluation 
model.  Included  in  this  methodology  is  a  description  of  tasks  or  procedures 
required  to  evaluate  the  effectiveness  of  a  system.  The  eight  tasks  are 
defined  as  follows: 

1.  Define  mission  objectives  (from  problem  definition) 

2.  Describe  system  states  (from  candidate  system  synthesis) 

3.  Specify  figure  of  merit(s)  (FOM) 

4.  Identify  accountable  factors 

5.  Select  model 

6.  Acquire  data  (from  data  bank) 

7.  Estimate  model  parameters 

8.  Exercise  model 

These  eight  tasks  are  essential  to  the  effectiveness  evaluation  of  candidate 
systems  as  a  part  of  the  integrated  control  design  methodology  (ICDM).  Two 
of  these  tasks  are  accomplished  during  Steps  1  and  2  of  the  ICDM  design 
methodology.  Reference  15  describes  the  intent  of  each  task.  The  specific 
intent  of  each  task  for  the  ICDM  is  described  below.  The  required  inputs, 
outputs  generated,  and  activity  flow  are  shown  in  Figure  25. 
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3.  5.3. 1  Definition  of  Mission  Objectives- -The  mission  objective  definition 
is  a  precise  statement  of  the  intended  purpose(s)  of  the  system,  of  the 
environmental  conditions  (natural  and  man-made)  and  of  the  threat(s) 
under  which  it  is  required  to  operate.  An  example  of  a  mission  objective 
statement  might  read  as  follows:  to  penetrate  enemy  defenses  and  kill 
long  range  enemy  gun  emplacements  with  a  probability  of  kill  of  0.  75  per 
sortie.  Environmental  conditions  might  be; 

•  Day /night  operations 

•  500  foot  ceiling,  3000  foot  visibility 

•  50  mm,  4  quad  enemy  defense 

This  brief  description  establishes  the  measure  of  effectiveness  as  a  kill 
probability  and  establishes  the  model  input  requirements,  that  is,  the 
environment  and  threat  conditions. 

3.  5.3.2  Definition  of  ICOF  Operational  States--The  objective  of  this  task 
is  to  establish  the  relationship  between  the  fully  operational  system  and  the 
mission  objective(s).  Inputs  from  Steps  1,  2,  and  3  of  the  ICDM  will  be 
required  for  accomplishing  this  objective.  Task  activity  will  include: 

1.  System  description--Acquire  a  detailed  understanding  of  the 
candidate  ICOF  system  designs  and  their  functions  as  defined 
in  Step  3  of  the  classical  steps  for  ICDM. 

2.  Mission  profiles--Acquire  established  mission  time  lines 
showing  the  sequences  of  principal  events  from  initiation  of  each 
mission  to  completion.  The  principal  events  should  be  correlated 
with  both  the  mission  segment  and  system  functions  defined  above. 
Data  provided  from  Steps  1  and  2  of  the  five  classical  steps  for 
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ICDM  will  be  used  as  inputs.  This  delineation  will  split  the  mission 
into  a  number  of  discrete  time  intervals  during  which  different 
functions  are  being  performed. 

3.  Mission  event  outcomes --Define  the  qualitative  and  quantative 
measure  of  the  complete  mission  (kill  enemy  gun  emplacements) 
and  intermediate  outcomes  of  the  principal  events  defined  above. 

An  example  of  a  principal  event  might  include  the  joint  event  of 
flying  below  300  feet  and  navigating  to  a  check  point  within  a 
CEP  =  100m  over  a  distance  of  25  km. 

4.  System  state  diagram- -Correlate  the  operational  hardware  with 
the  system  functions  that  must  be  performed  within  the  mission 
segments  (profile)  to  accomplish  the  desired  mission  outcomes. 

The  mission  state  diagram  identifies  the  components  used  to 
perform  the  functions  within  each  mission  segment  along  with 
their  contribution  to  mission  success.  In  addition,  the  system 
state  diagrams  will  account  for  new  system  design  techniques 
using  hardware  and  software  such  as  reconfiguration  and 
redundancy  management,  fault  isolation,  and  fault  tolerance  which 
will  permit  the  system  to  operate  in  an  alternate  state  of  equal 

or  degraded  performance. 

In  summary,  this  task  establishes  the  relationship  between  the  system 
elements,  their  state  of  operability,  and  mission  outcomes.  This  is 
essential  in  structuring  an  effectiveness  evaluation  model. 
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3.  5.3. 3  Specification  of  Figure(s)  of  Merit  (FOM) — Figure(s)  of  merit 


serve  to  quantify  what  is  expected  of  the  system.  They  must  be  in  an 
operationally- oriented  form  that  can  be  readily  understood  and  utilized 
in  planning.  An  FOM  usually  corresponds  to  the  mission  outcome  (which 
is  significantly  different  from  a  hardware  performance)  and  is  defined  as 
the  probabiUty  of  a  successful  outcome.  The  specified  FOM(s)  define  a 
system  effectiveness  vector.  For  example,  for  the  mission  objective 
defined  in  subsection  3. 5.3.1,  the  desired  outcome  is  to  kill  (put  out  of 
commission)  large  gun  emplacements.  The  probability  of  kill  (0.75)  is 
the  desired  measure  or  effectiveness  of  the  system  in  accomplishing  this 
mission  outcome.  For  the  ICDM  the  FOM  will  be  limited  to  a  single  mission 
objective  so  that  the  effectiveness  measure  is  a  scalar  quantity. 

3. 5. 3. 4  Identification  of  Accountable  Factors--Accountable  factors  are 


those  driving  factors  which  are  known  or  suspected  to  have  a  significant 
influence  on  the  figure(s)  of  merit  selected  for  the  system  effectiveness 
evaluation.  All  assumptions  which  are  made  in  regard  to  these  factors 
must  be  explicitly  stated.  Since  the  ICD  methodology  is  to  be  used 
specifically  in  the  planning  phase  and  for  concept  definition,  it  is  essential 
to  preface  all  effectiveness  analysis  with  a  list  of  the  assumptions  concerning- 

•  The  intrinsic  failure  and  repair  characteristics  of  the  components 
(for  example,  exponential  distributions,  extrapolation  techniques) 

•  The  maintenance  policies  in  effect  (for  example,  preventive 
maintenance  schedules,  checkout  procedures),  and 

•  The  environmental  conditions  under  which  the  system  is  to  operate 
(for  example,  temperature  extremes,  vibration,  enemy  counter¬ 
measures,  etc. ). 
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In  addition,  parametric  studies  to  investigate  the  sensitivity  of  these  factors 
shall  be  based  on  realistic  excursions  established  by  the  verification  of  the 
assumptions  made  above.  Table  26  is  a  checklist  for  identification  of 
accountalbe  factors  for  the  ICDM. 

3. 5. 3. 5  Construction  of  Model--The  model  describes  the  system  attributes 
required  and  how  they  will  be  combined  to  predict/estimate  system 
effectiveness  (FOM).  The  basic  model  selected  for  ICDM  is  shown  in 
Figure  26.  It  is  based  on  the  model  structure  established  by  WSELAC  with 
a  modification  to  include  the  attribute  of  survivability  and  the  impact  of  the 
man-machine  interface  in  terms  of  pilot  response.  Model  descriptions  will 
be  given  in  subsection  3. 5.  4. 

3.  5.  3.  6  Acquisition  of  Data- -The  importance  of  establishing  a  data  base 
for  the  ICDM  is  clear.  The  accountable  factors  as  indicated  in  subsection 
3.  5.  3. 4  and  the  inputs  required  for  the  models  as  indicated  in  subsection 
3.5.4  define  the  data  element  requirements.  Data  element  requirements 
must  be  clearly  stated  to  correspond  to  the  level  of  detail  specified  by  the 
models.  Sources  of  data,  methods  of  collection  and  extrapolation,  and 
format  must  be  clearly  defined.  The  completeness,  the  appropriateness, 
and  the  compatibility  of  available  sources  of  data  constitute  the  largest 
cause  for  differences  in  the  evaluation  of  effectiveness  from  one  development 
stage  to  another  in  the  system  life.  During  the  conceptual  stage,  for  which 
the  ICD  methodology  is  being  developed,  heavy  reliance  must  be  placed 
on  generic  data  for  component  and  subsystem  characteristics,  on  results 
learned  from  similar  systems,  and  on  application  of  basic  knowledge  about 
the  physical  laws  appropriate  to  the  system  concept.  This  information  can 
be  .red  in  the  parameter  estimation  task  defined  below. 
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TABLE  26.  CHECKLIST  FOR  IDENTIFICATION  OF 
ACCOUNTABLE  FACTORS 


System  Hardware  Description 

Spares 

•  Modes  of  operation 

•  Provisioning 

•  Hardware  organization 

•  Storage 

•  Software  organization 

•  Packaging 

Compatibility 

Transportation 

(e.g. ,  Electromagnetic 

Support  Equipment 

compatibility) 

•  Test 

Survivability 

•  Transport 

Vulnerability 

•  Maintenance 

Deployment 

•  Facilities 

Geographic  Factors 

Procedures  /Policies 

•  Deployment 

•  Operating 

•  Geology 

•  Repair 

•  Climate 

•  Inspection/Maintenance 

•  Atmospheric  phenomena 

•  Testing 

Personnel 

System  Interfaces 

•  Operating 

•  Support  systems 

•  Maintenance 

•  Force  mix 

•  Strategic  Integrated 

operations  Plan  (SIOP) 

WSEIAC  EFFECTIVENESS  MODEL 


Figure  26.  System  Effectiveness  Evaluation  Model  Structure  for 
ICOF  Systems 


3.  5. 3.  7  Estimation  of  Parameters- -Processing  the  data  elements  to 
derive  numerical  estimates  for  the  parameters  required  in  the  models 
is  the  next  task.  The  analytical  techniques  used  to  reduce  the  data  are 
referred  to  as  parameter  estimation  techniques.  The  specific  methods 
will  depend  upon: 

•  The  nature  of  the  parameter  being  estimated 

•  Available  data 

•  The  format  of  data  collection. 

As  previously  stated  the  ICDM  is  to  be  used  as  a  planning  tool  in  the  early 
concept  definition  phase.  Extrapolation  techniques  must  be  used  in  parameter 
estimation,  because  there  will  be  no  experimental  data  on  the  system  being 
synthesized. 

3.  5.  3. 8  Exercise  of  Model — The  system  effectiveness  vector  (scalar  in  the 
case  of  ICDM)  is  now  calculated  using  the  model  equations  and  parameter 
inputs.  This  is  an  iterative  process  in  which  variations  in  accountable 
factors  will  be  made  to  determine  parameter  sensitivity  either  locally, 
on  each  attribute,  or  globally,  on  total  system  effectiveness.  This  process 
is  discussed  in  more  detail  in  subsection  3.  5.4,  Model  Description. 

Reference  15  (pp  17-21)  provides  additional  discussion  of  the  eight  tasks 
listed  above  and  how  they  differ  during  the  four  major  system  phases: 

(1)  Conceptual  phase,  (2)  Definition  phase,  (3)  Acquisition  phase,  and  (4) 
Operational  phase. 
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3.5.4  Model  Description 


The  system  effectiveness  evaluation  model  selected  for  ICDM  is  shown  in 
Figure  26.  This  model  is  based  on  the  guidelines  provided  by  the  WSEIAC 
reports  with  modifications  to  include  evaluation  of  system  survivability 
and  the  impact  of  the  man- machine  interface.  This  model  was  selected 
because  it  meets  all  the  requirements  defined  in  subsection  3.5.2,  and  it  is 
particularly  well  suited  for  use  during  the  conceptual  phase  of  a  system 
development. 

First  of  all,  the  guidelines  provided  by  WSEIAC  stress  the  importance  of 
relating  effectiveness  to  the  mission  objectives.  In  this  way  there  is  a 
quantitative  functional  relationship  between  the  mission  objective  and  system 
design  (including  the  maintenance  and  logistic  structure).  This  provides  a 
better  understanding  of  the  design  drivers  and  data  to  substantiate  design 
decisions. 

Secondly,  the  WSEIAC  guidelines  recognize  that  during  the  conceptual 
phase  little  detail  will  normally  be  available  describing  the  specific 
hardware  and  software  elements  of  the  system.  It  therefore  provides  for 
parameter  estimating  techniques  and  probability  theory  to  compute  the 
different  system  attributes  (that  is,  availability,  dependability,  etc. ). 
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Thirdly,  the  WSEIAC  model  approach  is  flexible  and  allows  for  new  design 
techniques  for  reconfiguration,  fault  isolation,  and  fault  tolerance.  The 
level  of  detail  provided  by  the  model  and  its  flexibility  permit  detailed 
sensitivity  studies  to  identify  areas  of  inadequacies  in  system  design. 

And  finally,  an  analytic  approach  (as  opposed  to  a  Monte  Carlo  simulation) 
is  used  which  provides  a  realistic  and  manageable  evaluation  process. 

The  effectiveness  evaluation  model  overview  is  shown  in  Figure  27.  The 
cost  model  is  shown  because  it  will  provide  estimates  of  equipment 
(component)  MTBFs  and  individual  availabilities  (c^  *s)  required  to  compute 
the  dependability  and  availability  matrix  elements.  The  decision  is  based 
on  the  high  degree  of  interaction  between  equipment  design,  reliability, 
logistics,  maintenance  concept,  availability,  and  support  costs. 

The  cost  models  are  discussed  in  more  detail  in  subsection  3.4.5.  The 

PRICE  (Programmed  Review  of  Information  for  Costing  and  Evaluation) 

models  are  shown  as  an  interim  to  the  recommended  model.  The  PRICE 
42 

Models  are  a  family  of  three  cost- estimating  models:  (1)  basic  PRICE 
model,  which  estimates  development  and  production  cost  of  hardware, 

(2)  PRICE  L,  which  provides  maintenance  and  support  costs  of  hardware 
products  and  systems,  and  (3)  PRICE  S,  providing  for  design,  implementation, 
and  test  costs  of  all  types  of  deliverable  computer  software.  A  description 


42M.H.  Burmesiter,  "Parametric  Analysis  of  Design  to  Life  Cycle  Cost,  " 
from  Price  Systems  RCA  Corporation,  Cherry  Hill,  N.J.,  Published  in 
Proceedings  of  the  IEEE  1980  National  Aerospace  and  Electronics  Con¬ 
ference,  NAECON  '80,  May  1980  (pp.  675-681),  Vol.  I. 
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Figure  2  7.  Effectiveness  Evaluation  Model  for  ICDM 


1 


of  the  PRICE  models  here  is  beyond  the  scope  of  this  report.  In  summary, 
PRICE  includes  all  the  important  accountable  factors  required  to  estimate 
MTBF's  and  individual  equipment  or  component  availabilities.  For  example, 
the  PRICE  L  model  examines  deployment  and  employment,  sorts  through 
28  different  maintenance  concepts,  and  automatically  selects  the  most 
cost-effective  maintenance  concept.  In  addition  to  cost,  the  PRICE  models 
output  equipment  predicted  field  MTBF,  operational  availability,  and 
operational  readiness  as  a  function  of  maintenance  concepts  which  are 
used  to  compute  the  dependability  matrix  and  availability  vector  respect¬ 
ively.  The  PRICE  model  was  selected  primarily  because  it  is  the  most 
up-to-date  model  widely  used  in  the  U.S.  Government  and  industrial  circles. 
PLANET  is  a  Monte  Carlo  simulation  of  availability  for  multiple  aircraft 
systems,  given  demand  rates,  failure  rates,  and  logistic  support  parameters. 
Set  up  time  and  cost  to  run  such  a  model  did  not  meet  the  model  requirements 
defined  for  ICDM.  GEMM  is  in  many  ways  similar  to  PRICE  but  was 
judged  to  be  somewhat  out-of-date.  The  model  would  have  to  be  updated  to 
include  software  design  considerations. 

3»  5.4. 1  Model  Inputs- -Model  inputs  required  to  initiate  the  effectiveness 
evaluation  of  candidate  ICOF  systems  are  derived  from  ICDM  Steps  1  through 
3.  The  basic  inputs  include: 

•  Mission  requirements  and  performance  goals 

•  System  functions 

•  System  configuration/description 
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These  inputs  to  the  eight  tasks  defined  in  the  effectiveness  evaluation 
process  (subsection  3.5.3)  will  establish  model  inputs  and  configuration 
to  perform  the  multiple  runs  required  for  systems  evaluation  and  trade 
studies.  A  detailed  discussion  of  the  ICDM  effectiveness  evaluation  model 
is  provided  below. 

3. 5.4.2  System  State  Diagrams--System  state  diagrams  define  the  operating 
states  of  the  system  (that  is,  what  equipment  is  on  or  failed  and  what  system 
function  is  impacted).  State  diagram  formulation  is  extremely  important 
because  it  dictates  how  the  calculations  of  the  individual  effectiveness 
attributes  of  availability,  dependability,  survivability  and  capability  must 
be  structured.  For  ICDT  the  following  diagram  formulation  procedures 
will  be  used. 

•  A  system  state  defines  equipment  that  is  operating  or  failed 
and  either  provides  full,  degraded,  or  zero  performance  for 
one  or  several  system  functions. 

•  A  software  program  will  be  treated  like  hardware.  Both  hardware 
and  software  must  be  operating  if  required  for  a  specific  function. 

•  State  transitions  must  be  possible  for  either  failed  states  or 
repaired  states. 

A  system  state  diagram  applicable  to  all  possible  ICOF  configurations  is 
not  proposed  at  this  time.  State  diagrams  are  highly  dependent  upon  the 
mission  and  system  configured  to  meet  mission  requirements.  However, 
this  may  change  after  the  ICDM  has  been  applied,  when  it  can  be  shown 
that  one  generalized  model  may  satisfy  all  ICOF  configurations  where 
some  states  are  empty  for  some  systems. 
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3.  5. 4.  3  Mission  Profile /System  Function  Model--The  mission  model 
and  system  functions  are  correlated  through  the  use  of  a  time  line  which 
defines  discrete  mission  segments  and  system  functions  required  to  meet 
each  segment  requirements.  This  process  and  the  results  will  be 
illustrated  in  subsection  3.5.5. 

3.  5. 4. 4  Miss  ion /System  Model--System  state  diagrams  are  correlated 
to  the  mission  profiles  to  establish  the  mission/system  elements  to  the 
effectiveness  evaluation  models.  This  process  and  resulting  model  will 
be  illustrated  in  subsection  3. 5.  5. 

3.  5.4.  5  Availability  Model — The  WSEIAC  availability  model  structure  was 
selected  as  part  of  the  effectiveness  evaluation  for  ICDM.  This  model  is 
defined  in  detail  in  Reference  15.  A  summary  description  of  the  model 
is  given  below. 

First  of  all,  by  definition,  availability  is  a  measure  of  the  system  condition 

(repaired  or  failed)  at  the  start  of  a  mission,  when  the  mission  is  called 

for  at  an  unknown  (random)  point  in  time.  There  are  other  terms  used  to 

describe  the  system  state  at  the  beginning  of  a  mission.  For  example,  one 

concept  of  operational  readiness  includes  calendar  time  while  availability 

includes  only  desired  use  time.  For  the  ICDM,  "Availabilijy  is  the 

probability  that  the  system  will  operate  satisfactorily  at  any  point  in  time 

43 

when  used  under  stated  conditions.  "  The  availability  of  any  one  unit 


43 


See  Reference  15 


in  the  system  is  given  by: 


-  MTBF(i) 

i  '  MTBF(i)  +  MDT(i) 

where  MTBF(i)  =  the  meantime  to  failure  of  unit  i 
MDT(i)  =  the  meantime  to  repair  the  unit  i 

MDT(i)  is  highly  dependent  upon  both  the  system  design  and  the  maintenance 
concept.  MDT  must  therefore  be  determined  using  a  logistic /maintenance 
model.  Having  the  availabilities  for  the  individual  units  (modules,  com¬ 
ponents,  equipment),  we  can  then  compute  the  system  availability  vector  A. 


The  system  availability  is  defined  by  a  vector.  A,  which  is  a  row  vector 
[al»  ,  a^]  containing  the  probabilities  of  the  various  defined  system  states 
when  the  mission  begins.  This  vector  will  be  computed  from  the  individual 
unit  availabilities  using  probability  theory,  that  is,  a.  is  the  product  of  the 
Oj  *s  and  (l-a.Vs  (or  unavailabilities).  For  example  if  a.  is  defined  as  the 
probability  that  all  N-units  are  available 

a,  =  ??„. 

1  i-1  1 

Also  if  is  defined  as  the  system  state  where  component  l(i=l)  is  not 
available 

a2  = 

This  process  of  combining  the®  ^'s  according  to  the  state  diagram  model 
will  continue  until  all  states  are  accounted  for  and  the  availability  vector 
A  is  defined.  This  process  and  the  model  structure  will  be  illustrated  in 
subsection  3. 5.  5. 


i 


3.5.4. 6  Dependability  Model — The  WSEIAC  dependability  model  structure 
was  selected  as  part  of  the  effectiveness  evaluation  for  ICDM.  This  model 
is  defined  in  detail  in  Reference  15.  A  summary  description  of  the  model 
is  given  below. 

By  definition,  dependability  is  a  measure  of  the  system's  condition  during 
the  mission.  Two  possible  concepts  exist:  (1)  no  in-flight  repair,  that  is, 
if  a  system  fails  it  remains  in  the  failed  state  until  the  aircraft  returns  to 
base  for  repair  or  (2)  in-flight  repair  in  which  the  system  can  be  restored 
to  one  of  its  operational  states.  Note  that  the  later  does  not  include  any 
automatic  reconfiguration  or  redundancy  since  these  will  be  considered 
in  tve  system  state  diagram. 

In  the  first  concept  the  aircraft  will  either  continue  in  a  degraded  but 
acceptable  state  or  return  to  base.  The  second  concept  implies  that  a 
system  has  been  designed  for  in-flight  repair  ability  and,  although  such 
actions  must  remain  simple,  does  provide  for  capability  of  restoring  the 
system  to  a  former  operational  state.  The  dependability  model  proposed 
for  ICDM  includes  in-flight  repairability  as  structured  in  the  WSELAC 
reports.  Thus  dependability  is  the  probability  that  the  effective  state  of 
the  system  during  the  mission  is  j,  given  that  the  mission  was  initiated  in 
state  i  and  providing  that  a  downtime  per  failure  not  exceeding  a  given  lapse 
time  (t)  will  not  adversely  affect  the  overall  mission  success. 


i 
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From  Reference  15,  system  dependability  is  represented  as  a  matrix 


where 


[D] 


lll 

d12 

nl 

n2  *** 

nn 

and 


d„'s  -  are  the  probabilities  that  the  system  will 
be  in  state  3  at  the  end  of  a  mission,  given 
that  it  was  initially  in  state  i 


j]  d..  =1  ,  i  =  1,2, . .  n 

j=l  1J 

n  =  number  of  system  states 

The  specific  formulation  of  the  dependability  matrix  depends  upon  the  effect 
of  the  failures  during  the  mission  and  whether  or  not  repair  is  possible 
during  the  mission. 


A  simple  example  will  be  used  to  explain  the  dependability  model.  The 
system  consists  of  one  piece  of  equipment  that  must  be  in  one  of  the  two 
states  at  the  time  of  mission  demand:  namely,  operable  or  failed.  Thus, 
we  consider  a  2  x  2  matrix: 


P] 


11 

d12 

21 

d22 

146 


1 


where  the  d, .  *s 

ij 


have  the  following  interpretations: 


dn  =  The  probability  that  the  system  is  operable  at  the 
end  of  the  mission,  given  that  it  was  operable  at 
start  of  the  mission. 


^12  =  Probability  tbat  the  system  is  failed  at  the  end 
of  the  mission,  given  that  it  was  operable  at  the 
start  of  the  mission 


d^i  =  The  probability  that  the  system  is  operable  at  the 
end  of  the  mission,  given  that  it  was  failed  at  the 
start  of  the  mission. 


d  =  The  probability  that  the  system  is  failed  at  the  end 

U  Ci 

of  the  mission,  given  that  it  was  failed  at  the  start 
of  the  mission. 


The  model  required  to  compute  these  probabilities  is  described  below. 

Model  assumptions  are  that  times  to  failure  after  repair  actions  and  times 
to  repair  after  failures  are  exponentially  distributed  for  the  ICOF  system. 
This  means  that  the  probability  of  a  failure  or  a  repair  in  a  small  increment 
of  time  (At)  can  be  expressed  as 

•  Probability  of  failure  in  time  At  =  XAt 

•  Probability  of  a  repair  in  time  At  =  /uAt 
where 

X  =  system  failure  rate 
fj.  -  system  repair  rate 


With  this  assumption,  the  differential  equation  for  the  probability  that 
the  system  will  be  in  system  state  (1)  is 


d  P^t) 
dt 


(X  +n)  Pj(t)  +p 


The  general  solution  to  this  differential  equation  is  found  to  be 


Pjit)  = 


At 

\+H 


!  - 


+  P^o)  e 


~(\+ld)t 


where  P^(o)  is  the  probability  that  the  system  is  operable  at  t  =  o.  By 
difinition  P^(o)  =  1  at  t  =  o,  then  d^  is  the  value  of  P^(T)  when  Pj(o)  =  1, 
and  dgi  is  the  value  of  P^(T)  when  P^(o)  =  o,  where  T  is  the  duration  of 
the  mission.  Thus 


d 


11 


d 


12 


M  + 

X  -(X-hi)T 

X  +fj. 

1  ■  dn 

X+M 

x  ( 

f  \ 

l-e-(X+^)T] 

X  +  p  ' 

t  / 

X 

!.e-(X+M)T 

X  +  id 

^l 

L  -1 

=  X  +  id  -(Xhu)T 
X+ju  X4 p  e 
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Now  if  we  assume  that  in-flight  repair  is  not  used  in  the  ICOF  design, 
H  =  o  and  the  equations  become 


dll 

=  e-XT 

=  1  -  e_XT 

d12 

d21 

=  0 

^22 

=  l 

which  are  consistent  with  equations  derived  assuming  no  in-flight  repair- 
ability. 

The  next  step  is  to  expand  the  dependability  matrix  to  include  an  n-state 

system.  This  can  be  done  by  considering  the  dependability  of  each  unit  in 

the  system  state  diagram  and  combining  their  probabilities  according  to 

the  rules  of  statistics.  A  technique  for  computing  these  probabilities  has 

been  modeled  in  a  program  named  SESIP  (System  Effectiveness  State 

44 

Diagram  Interactive  Program).  This  model  was  developed  by  Honeywell 

for  the  government  to  facilitate  the  analysis  of  complex  multiphase,  multi- 

mode  and  multimission  systems  such  as  the  ICOF  system.  The  basic 

structure  of  the  program  is  the  same  as  that  of  the  earlier  SIP  (State 

Diagram  Interpretive  Program)  developed  under  Air  Force  contract  AF 
45 

33(61 5)-2475.  Inputs  to  the  program  are  the  state  diagram  model  with 

44 

J.  M.  Thuirer  and  L.  L.  Montague,  SESIP  Computer  Program  Documentation, 
March  1970. 
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State  Diagram  Interpretive  Program;  A  Guide  for  Users,  U-ED  1600-1, 
December  1964.  Revised,  March  1966,  by  E.J.  Daum,  Honeywell,  Inc. 


indicated  equipment  failure  rates  and  repair  rates;  the  program  then  computes 
the  elements  of  the  dependability  matrix.  The  program  with  appropriate 
inputs  can  also  compute  system  availability  and  combine  the  three  attributes 
of  availability,  dependability,  and  capability  to  compute  systems  effectiveness. 
It  is  recommended  that  the  program  be  modified  to  include  survivability  which 
requires  incorporation  of  another  matrix  multiplication.  Program  description 
is  given  in  reference  44  and  45.  The  procedure  as  illustrated  in  the  example 
problem  is  subsection  3.5.5. 


th 

3.  5.4.  7  Capability  Model- -Capability  is  a  measure  of  the  k  figure  of 

merit,  conditional  on  the  given  system  state  j.  Thus  the  element  C.. 

th 

of  the  capability  matrix  is  the  k  figure  of  merit  (or  mission  objective) 

associated  with  system  performance  in  system  state  j.  For  ICDT  we  will 

consider  only  one  FOM  and  therefore  C.  is  a  vector.  The  magnitude  and 

J 

dimensions  attached  to  this  figure  of  merit  depend  upon  the  specific 

nature  of  the  system  undergoing  evaluation.  For  example,  the  ICOF 

system  might  be  designed  for  an  aircraft  delivering  weapons  to  within  some 

specified  miss  distance.  The  calculation  of  each  C.  could,  in  this  case, 

J 

require  an  accounting  for  the  targeting  policy,  weapon  dispersion,  weapon 
sighting  system,  flight  control,  terrain  avoidance,  navigation,  communication, 
IFF,  instrumented  landing,  and  the  man-machine  interface. 


Because  the  C/s  depend  so  specifically  on  the  type  of  system  designed 
and  mission  to  be  performed,  the  capability  model  must  be  correlated  to 
the  system  state  diagram  and  the  mission  profile /system  function  profile 
defined  for  the  system.  This  will  be  explained  in  more  detail  in  the 
example  given  in  subsection  3. 5.  5. 
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The  proposed  capability  models  for  ICDM  will  consist  of  the  performance 
models  defined  for  the  functional  performance  evaluation  modified  to  include 
the  pilot  response  input  from  the  man- machine  queuing  model.  Provisions 
shall  be  made  to  transform  system  capability  to  a  probability  of  mission 
success. 

3. 5.  4.  7. 1  Equipment  Capabilities — As  stated  above  the  output  of  the 
functional  (equipment)  performance  models  defined  in  subsection  3.5.2  must 
be  in  terms  of  or  converted  to  probabilities  of  success.  For  example,  if 
the  mission  requirements  are  such  that  an  aircraft  must  navigate  to  within 
x-feet  of  a  checkpoint  and  this  can  only  be  accomplished  50  percent  of 
the  time  with  a  selected  navigation  design,  the  probability  of  navigation  success 
is  .5.  Thus  the  equipment  capability  models  will  be  extremely  dependent 
upon  the  definition  of  mission  requirements  and  the  method  of  computing 
equipment  performance.  In  addition,  the  equipment  performance  models 
must  consider  modeling  impact  of  pilot  response  delays,  that  is,  the  fraction 
of  time  the  pilot  may  be  delayed  (because  of  work  load)  during  the  mission 
(for  example,  position  accuracy  degradation).  Pilot  delays  shall  be 
generated  by  the  queuing  model  discussed  below. 

3. 5. 4.  7.2  Pilot  Queuing  Model- -A  simplified  queuing  model  is  used 
for  evaluating  the  impact  of  man- machine  interfaces  on  ICDM  performance 
during  the  concept  definition  phase.  This  conclusion  is  based  upon  a 
survey  of  existing  analytical  techniques  for  aircrew  work  load  analysis 
and  on  judgment  based  on  past  experience  with  previous  studies  of  this  kind. 

The  rationale  for  the  conclusion  is  as  follows: 

1.  Pilot  work  load  models  are  system-detail  orientated  and  require 
a  lot  of  manual  labor  to  set  up. 
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2.  Pilot  wor  k  load  models  are  cumbersome  to  manipulate  and 

not  conducive  to  fast  turnaround  in  performing  design  trade-off 
studies. 

3.  Because  we  are  addressing  the  concept  definition  phase,  there 
will  be  no  cockpit  mock-ups  to  provide  detail  work  load  lapse 
times . 


The  analogy  of  queuing  (or  waiting  line)  to  pilot  activities  is  clear  from  the 
work  load  analysis  models  used  in  the  past,  (that  is,  considering  the  number 
of  tasks,  task  times,  and  the  amount  of  time  available  to  do  the  tasks 
determined  when  the  pilot  was  saturated).  The  primary  difference,  however, 
is  in  technique.  Rather  than  use  specific  tasks,  task  times,  etc.,  queuing 
theory  uses  probability  density  functions  such  as  for  a  service  facility 
during  any  specified  time  interval.  The  service  facility  in  this  case  is  the 
pilot  at  the  controls  of  the  aircraft.  The  average  length  of  the  waiting  line 
establishes  the  response  delay  of  the  pilot  in  performing  the  required 
system  actions. 


A  simple  example,  using  the  queuing  method  described  in  Reference  46 
will  demonstrate  the  technique.  Consider  a  sequence  of  tasks  (messages) 
which  must  be  performed  on  the  average  of  once  every  10  seconds  (task 
arrivals)  and  with  Poisson  distribution; 

(XT)n  e~^ 

P  (n)  =  - 

T  o 

n. 


46 

Guidebook  for  Systems  AnalyBis/Cost-Effectiveness,  prepared  for  U.S. 
Army  Electronics  Command  under  Contract  DAAB07-68-C-0056,  March 
1969. 
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where 
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where 


Pc  =  probability  of  successfully  completing  all  tasks 
Kp  =  constant  of  proportionality 

n  =  average  number  of  tasks  in  the  queue  (either  waiting 

cl 

to  be  performed  or  being  performed) 


The  selection  of  should  be  based  on  experimental  data.  In  this  case 

we  will  select  K  =  2  for  P  =1  and  n  =1.  This  says  that  if»  on  the 

pcs 

average,  there  is  only  one  (1)  task  in  the  queue,  the  probability  of  pilot 
success  is  one  (1). 

For  this  particular  type  of  a  queue  the  average  number  of  tasks,  n  ,  in 

cl 

the  system  is  given  by: 

2 

/u  -  X 

_1_ 

T 

a 

1 

Tg 

For  a  given  X  *  .1,  the  average  service  times  for  performing  the  tasks 

can  be  studied  parametrically.  For  example  let  t  =8  seconds,  then 

s 

n  =4.0 
a 


n 

a 

where 

X 


154 


Using  the  expression  for  pilot  performance 

P  =0.4 
c 

We  can  also  compute  the  average  delay  (pilot  response)  resulting  from  the 
system  queue.  If  t  =8  seconds  and  n  =  4  we  can  expect,  assuming  all 
tasks  must  be  performed,  a  task  delay  of  32  seconds  (that  is,  t  =  r  X  n  ). 

S  cl 

The  results  of  this  analysis  provides  an  input  to  the  equipment  capability 
models  which  account  for  pilot  delay  (Figure  28). 

If  the  pilot  response  and  performance  are  not  adequate,  a  system  redesign 
to  reduce  either  the  task  rate  of  arrival  or  task  rate  of  service  through 
automation  or  some  other  techniques  can  be  examined. 

3.  5.4.  7.3  Total  System  Capability- -The  total  system  capability  is 

derived  by  combining  the  equipment  capability  (probabilities)  and  pilot 

capability  (probability)  for  each  possible  system  state,  j  =  1,2, . . , 

Figure  28  shows  the  analysis  flow  for  three  major  system  functionsi  flight 

control,  navigation,  and  weapon  control.  Assuming  a  mission  phase/ 

equipment  state  in  which  all  three  major  functions  are  required  and  in 

which  the  probability  of  flight  control  (P  ),  navigation  (P  )  and  weapon 

control  (P  )  along  with  pilot  performance  (P„)  are  defined,  the 

w  c  ^  ^ 

combined  system  capability  for  the  j  equipment  state  is  given  by: 

r*  =  p  p  p  p 

j  FC  *  N  '  WC  ’  C 


155 


Figure  28.  Capability  Model 


3.  5. 4.  8  Survivability  Model- -The  design  of  survivability  for  a  controi-of- 
flight  system  must  take  into  account  the  structural  and  survivability  design 
of  the  aircraft  that  the  system  is  being  designed  to  control.  Likewise 
the  quantitative  evaluation  of  the  survivability  for  a  given  COF  design 
or  configuration  must  include  as  inputs  some  aircraft  geometric  structural 
and  performance  characteristics.  The  approach  to  synthesizing  the 
survivability  aspect  of  the  COF  system  to  complement  the  aircraft's 
survivability  design  is  described  in  Reference  37.  The  analysis  of  the 
survivability  of  the  integrated  system  is  a  significant  part  of  the  iterative 
process  that  the  complexity  of  survivability  design  requires.  It  is  also 
part  of  the  overall  system  effectiveness  evaluation  step.  The  model 
recommended  for  the  ICDT  methodology  is  described  in  the  following 
subsections. 

3. 5.  4. 8. 1  Background- -The  survivability  model  recommended  for 
the  ICDT  methodology  was  developed  by  Honeywell  during  a  study  of 
flight  control  survivability  through  use  of  on-board  digital  computers 
(Reference  37).  The  acronym  SUDIC  was  applied  to  this  study  and  the 
analytical  technique  that  was  transformed  into  the  survivability  model 
was  referred  to  as  the  Quick  Analysis  model. 

The  essence  of  design  for  affordable  survivability  is  to  be  able  to  identify 
those  system  and  subsystem  configurations  that  are  more  survivable  with 
negative  or  small  penalties  in  the  other  -ilities. "  To  make  the  best  choices, 
it  is  important  to  be  able  to  readily  quantify  the  relative  survivability  of 
modifications  of  a  basic  system. 
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To  accomplish  this  quantification,  Honeywell  has  developed  the  software 
and  model  structure  to  analyze  the  survivability  and  reliability  of  a 
control- of-flight  system.  Its  applicability  is  broad  enough  to  consider 
control- of-flight  equipment  and  other  aircraft  subsystems  required  to 
supply  power  or  data  to  the  flight  control  system  (for  example,  hydraulic, 
electric,  and  air  data).  The  model  has  the  scope  to  show  the  effect  on 
survivability  of  functional  redundancy  and  the  dispersion  of  components 
used  to  duplicate  functions.  At  the  same  time,  the  problem  definition 
requirements  and  quick  computer  turnaround  minimize  the  resources 
required. 

The  initial  motivation  for  developing  this  survivability  analysis  model  was 
the  approaching  capability  of  digital  fly-by- wire  (DFBW)  systems  to  identify 
damage  to  the  FCS  or  surface  actuation  systems  and  to  change  control  laws 
to  enable  the  aircraft  to  fly  without  the  affected  components  or  surfaces. 

Technology  is  developing  for  improved  fault  isolation  within  computers 
(References  36,  47-49),  fault  isolation  in  sensor  sets  using  analytical 

47  - 

W.G.  Bouricius,  et  al. ,  "Reliability  Modeling  Techniques  for  Self- 
Repairing  Computer  Systems,  "  Proc.  ACM  1969  Annual  Conference. 

48 

J.H.  Wensley,  et  al.,  "Design  of  a  Fault  Tolerant  Airborne  Digital 
Computer,  "  NASA  CR132252,  October  1973  (SIFT-Standard  Research 
Institute). 

49 

R.  Kayfes,  et  al. ,  Interpretive  Computer  Simulation  for  the  Modular 
Spacecraft  Computer,  "  Logicon  Report  No.  CSS-7254-R1410,  November 
1972. 


redundancy  (References  50-52),  and  actuator  checking  through  input-output 
comparison.  An  additional  level  of  redundancy  (beyond  the  sensor  count) 
has  been  demonstrated  in  simulation  by  reconstructing  the  signal  of  a  failed 
gyro  using  other  measurements  and  the  analytical  redundancy  filter  that  is 
used  originally  to  identify  the  sensor  failure  (Reference  53). 

This  growing  capability  in  fault  isolation,  detection,  and  recovery  of  DFBW 
systems  is  opening  a  new  dimension  in  the  design  of  survivability  aircraft; 
this  is  the  idea  of  the  reconfigurable  control- of-flight  systems. 

3. 5. 4. 8. 2  Model  Description--In  the  design  stage  the  survivability 
analysis  method  using  the  Quick  Analysis  model  generates  quick  estimates 
of  the  survivability  of  a  particular  configuration  and  its  relation  to  the 
survivability  of  alternate  configurations.  The  SUDIC  study  assumes  that 


50 

J.  Deckert,  et  al. ,  ’’Reliable  Dual-Redundant  Sensor  Failure  Detection 
and  Identification  for  the  NASA  F-8  DFBW  Aircraft,  "  C.S.  Draper  Lab 
Report  R-1077,  Cambridge,  Maine,  May  1977. 

51 

T.  Cunningham,  et  al. ,  "Fault  Tolerant  Digital  Flight  Control  with 
Analytical  Redundancy,  "  AFFDL-TR-77-25,  May  1977  (Honeywell). 

52 

T.  Cunningham,  and  R.  Poyneer,  "Sensor  Failure  Detection  Using 
Analytical  Redundancy,  "  JACC  1977,  San  Francisco,  California,  J  ne 
1977. 

53 

T.  Cunningham,  J.  Doyle,  and  D.  Shaner,  "State  Reconstruction  for 
Flight  Control  Reversion  Modes,  "  IEEE  Control  and  Decision  Conference, 
New  Orleans,  December  1977. 
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all  capabilities  for  a  reconfigurable  system  are  in  hand.  The  analysis  method 
aids  the  designer  in  determining  which  capabilities  to  implement. 

The  six  major  steps  in  the  survivability  analysis  are  shown  in  Figure  29. 

They  include  all  the  features  involved  in  a  detailed  survivability  analysis. 

The  procedure  is  kept  efficient  by  using  simple  forms  for  much  of  the 
input  data  (Steps  1,  3)  and  by  using  independent  computer  programs  for 
different  parts  of  the  problem.  Once  Steps  2  and  4  are  completed,  they 
need  not  be  repeated  in  the  process  of  looking  at  many  practical  variations 
of  a  system. 

The  combinations  of  damage  events  to  components  that  are  required  to 
disable  sections  of  a  system  are  stated  by  writing  Boolean  algebraic 
statements  (Step  5).  The  combinations  of  damaged  sections  that  result 
in  system  kill  are  stated  by  writing  more  Boolean  statements.  In  Step  6, 
the  program  PKILL  combines  all  the  algebraic  statements,  component 
vulnerable  areas,  the  encounter  history  to  compute  kill  probability  of 
components  of  subsystems,  and  of  the  system.  Furthermore,  PKILL 
computes  data  useful  to  the  designer  in  determining  changes  that  will 
further  enhance  survivability. 

Noteworthy  aspects  of  this  survivability  analysis  method  are: 

•  The  comparative  simplicity  of  input  data,  and 

•  The  program's  conversion  of  Boolean  statements  of  damage 
events  (input)  into  probabilities  of  killing  components,  sub¬ 
systems,  and  a  system.  (Boolean  statements  are  better  for 
showing  the  improvement  from  functional  duplication  or 
triplication  than  the  single-hit  probability  models. ) 
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Figure  29.  Six  Major  Steps  in  Survivability  Analysi 


Data  preparation  is  kept  simple  primarily  by  having  only  a  limited  number 
of  choices  for  component  data.  A  component's  susceptibility  to  damage  is 
described  by  estimates  of  three  areas  (front,  left  face,  and  top)  and  seven 
integers.  The  first  six  integers  designate  a  shielding  category  which 
represents  an  average  shielding  by  other  parts  of  the  aircraft  for  each 
face  of  the  component.  (Currently  four  categories  are  used,  but  ten  are 
permitted.)  The  seventh  integer  describes  the  component's  intrinsic 
hardness  by  assigning  it  to  a  generic  family  of  PD/H  (probability  of  damage 
given  a  hit).  Up  to  15  families  (generic  component  types)  are  used  and  each 
family  has  up  to  five  curves  (one  for  each  of  five  projectile  types). 


During  design,  component  locations  in  an  aircraft  are  known  only  approxi¬ 
mately.  To  simplify  designation  of  component  location,  the  aircraft  is 
divided  into  seven  compartments  and  components  are  simply  assigned  to 
the  compartment  that  represents  the  appropriate  part  of  the  aircraft.  A 
component's  location  is  its  compartment's  centroid.  To  reduce  the  number 
of  components  considered,  highly  distributed  systems  may  be  assigned  to 
the  aircraft  mass  center  (the  eighth  compartment).  The  criterion  for 
choosing  compartment  boundaries  is  to  provide  resolution  of  the  shot-by¬ 
shot  hit  probability  distribution  from  the  encounter  history. 

Thus,  the  complete  physical  description  of  each  component,  together  with 
its  shielding  for  each  face,  requires  three  face  areas.  These  data,  to¬ 
gether  with  projectile  mass,  are  used  to  compute  a  component  vulnerable 
area  for  each  face  (Reference  37)  of  each  component.  An  eighth  integer 
assigns  the  component  to  a  compartment. 


162 


Component  kill  probabilities  are  computed  throughout  a  mission  using  the 
vulnerable  area  tables  and  the  encounter  history.  The  methods  are 
straightforward  and  are  described  in  detail  in  Reference  37.  A  significant 
feature  is  that  the  component  kill  probabilities  are  combined  according 
to  the  Boolean  rules  established  in  the  damage  modes  and  effects  analysis 
(Step  5)  to  yield  subsystem  and  system  kill  probabilities.  This  is  particularly 
important  for  two  reasons. 

First,  component  kill  probability  is  a  very  pessimistic  indicator  of  system 
kill  probability  whenever  the  component's  function  is  duplicated  by  equipment 
which  is  located  so  as  not  be  be  killed  by  the  same  shot.  Second,  a  single- 
hit- kill  probability  model  is  always  optimistic  when  a  component's  function 
is  duplicated  because  this  model  then  predicts  zero  kill  probability.  A 
Boolean  model  system  evaluates  kill  probability  according  to  the  degree 
of  functional  redundancy. 

3.5.5  Illustrative  Example- - 

3. 5.  5.1  Problem  Modeling — This  subsection  illustrates  the  system 
effectiveness  evaluation  procedures  using  the  state  space  system 
effectiveness  model.  The  formulation  used  is  directly  applicable  for 
simulation  using  the  SESIP  computer  program.  The  basic  problem  was 
taken  from  Reference  15,  Vol  III,  Example  A.  In  the  referenced  document, 
treatment  of  the  WSEIAC  effectiveness  formula,  not  including  the 
survivability  attribute,  was  illustrated.  This  subsection  treats  the  same 
problem  but  uses  the  state  space  system  effectiveness  model.  The 
survivability  aspects  of  the  example  are  described  in  separate  subsections. 


163 


3. 5.  5. 1. 1  Problem- -Determine  the  system  effectiveness  of  an 
avionics  system  developed  for  a  tactical  fighter -bomber  aircraft. 

3. 5.  5. 1.2  Mission  Definition-- At  any  time  when  an  execution  order 
is  received,  the  aircraft  shall  take  off  immediately,  receive  a  target 
assignment,  proceed  to  target  area,  deliver  weapon  within  500  feet  of 
target,  and  return  to  the  operating  base. 

3. 5.  5. 1.3  System  Description- -The  system  being  considered  consists 
of  three  major  subsystems  which  are,  where  appropriate,  subdivided  into 
equipments. 

Communication- 

Fire  Control  Subsystem  Doppler  Navigator  Identification- 

Navigation 

•  Radar  (search  and  •  Doppler  navigator  •  UHF  direction  finder 

terrain  avoidence) 

•  TACAN 

•  Toss-bomb  computer 

•  Instrument  landing 

•  Sight  system  system 

•  UHF  transmitter- 
receiver 

•  Identification  equip¬ 
ment 

•  Audio  amplifier 
equipment 

The  equipments  itemized  are  independent  of  each  other,  that  is,  the 
condition  of  any  equipment  does  not  influence  the  condition  of  any  other. 
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3. 5.  5. 1.4  Functions  of  Equipments --The  fire  control  subsystem  is 
employed  in  actual  weapon  delivery.  It  provides  a  radar  display  of  the 
target  and  computation  of  weapon  reLease  point  in  the  toss-bombing  mode. 

It  also  provides,  through  the  sight  system,  the  aiming  point  for  "lay-down" 
delivery.  The  terrain  avoidance  feature  provides  automatic  control  of  the 
aircraft  altitude. 

The  Doppler  navigator  provides  the  prime  navigation  function  by  computing 
and  displaying  information  on  both  present  position  and  distance /heading 
to  target.  Alternate  navigation  procedures  are  provided  by  the  Tacan  and 
the  UHF  direction  finder.  Each  of  these,  however,  requires  ground  station 
facilities. 

The  instrument  landing  system  (ILS)  provides  the  ability  to  land  the  aircraft 
under  ceiling  and  visibility  conditions  which  would  otherwise  prevent  landing. 

The  UHF  transmitter-receiver,  the  only  radio- communications  device, 
is  employed  for  all  in-flight  radio  communication.  The  audio  amplifier 
equipment  is  employed  with  the  UHF  transmitter- receiver  only  and  may  be 
considered  part  of  that  equipment. 

The  identification  equipment  (IFF)  provides  a  coded  identification  signal 
in  response  to  an  interrogation  by  friendly  forces.  Failure  to  provide 
the  proper  response  can  result  in  attack  by  friendly  forces. 
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3. 5.  5. 1.5  Functional  Breakdown- -The  essential  functions  to  be 
performed  by  the  avionics  system  are  listed  below: 

•  Communication 

•  Identification 

•  Navigation 

•  Penetration 

•  Weapon  delivery 

•  Landing 

3.  5.  5. 1. 6  System  Block  Diagram--A  general  block  diagram  of  the 
avionics  system  is  shown  in  Figure  30. 

3.5.  5.1.7  Mission  Profile- -A  time  line  representation  of  the  mission 
being  considered  is  shown  in  Figure  31.  Three  different  modes  of 
delivery  are  represented: 

•  Visual  lay-down  (VL) 

•  Visual  toss  (VT) 

•  Blind  toss  (BT) 

Basic  mission  breakdown  is  as  follows: 

0.0  -  0.5  hours  Proceed  to  target  area  (communicate,  navigate, 

identify) 

0.5  -  0.6  hours  Identify  target 


Figure  30.  Avionics  System:  Functional  Diagram 
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Figure  31.  Mission  Profile  and  Equipment  Usage 


0.6-  0.  65  hours 


Deliver  weapon 


0.65  -  1.15  Return  to  assigned  base  (navigate,  identify) 

1.15  -  1.2  Land 

3. 5.  5. 1.8  Delineation  of  Mission  Outcomes- - 

1.  Mission  is  accomplished  as  stated  in  mission  definition  paragraph. 

2.  Mission  is  not  accomplished  as  stated: 

•  Aircraft  does  not  proceed  without  delay 

--One  or  more  subsystems  are  in  a  state  that  prevents 
launching. 

•  Aircraft  does  not  receive  target  assignment 

— Failure  or  inadequacy  of  one  or  more  subsystems  prevents 
receipt  of  target  assignment 

•  Aircraft  does  not  deliver  weapon  within  500  feet  of  target. 
--Aircraft  does  not  reach  target  area 

Failure  or  inadequacy  of  one  or  more  subsystems  prevents 
reaching  target  area. 

--Aircraft  does  not  identify  target 

Failure  or  inadequacy  of  one  or  more  subsystems  prevents 
identification  of  target 

— Aircraft  does  not  place  weapon  within  500  feet  of  target. 
Failure  or  inadequacy  of  one  or  more  subsystems  results 
in  inaccurate  delivery. 


Aircraft  does  not  return  to  assigned  operating  base. 

— Aircraft  lost 

Failure  or  inadequacy  of  one  or  more  subsystems  results 
in  aircraft  loss. 

--Aircraft  returns  to  the  wrong  base. 

Failure  or  inadequacy  of  one  or  more  subsystems  prevents 
return  to  assigned  base. 


3.  5.  5. 1. 9  Specification  of  Figures  of  Merit- -For  the  specific  mission 
requirement,  the  major  figure  of  merit  is  the  probability  that  the  mission, 
as  defined,  is  accomplished. 

Accomplishment  of  the  mission  depends  upon  the  successful  performance 
of  several  individual  functions: 

1 .  Takeoff 

2.  Receipt  and  acknowledgement  of  target  assignment 

3.  Navigation  to  a  point  not  more  than  five  miles  from  target 

4.  Proper  identification  when  interrogated 

5.  Penetration  of  enemy  defenses 

6.  Identification  of  target  and  weapon  delivery  within  500  feet  of  target 

7.  Navigation  to  within  10  miles  of  assigned  operating  base. 

8 .  Landing 
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3.5.5.1.10  System  Model — The  system  model  must  express  the 
probability  of  successfully  completing  a  mission  as  a  function  of: 

•  The  effectiveness  of  the  system  in  each  of  the  three  delivery 
modes,  and 

•  The  probability  of  employing  each  delivery  mode. 


This  can  be  represented  by  the  following  simple  model: 


-2 


where 


E  =  system  effectiveness 
E.  =  system  effectiveness  in  mode  i 

Pj  =  probability  of  using  mode  i. 

In  the  given  problem  we  will  be  considering  three  different  delivery  modes. 
The  values  of  will  be  determined  from  consideration  of  tactical  require¬ 
ments  and  operational  conditions.  The  values  of  E^  will  be  derived  by 
combining  the  effectiveness  figures  for  each  mission  function  in  accordance 
with  the  requirements  for  the  stated  mission  mode. 

3.  5.  5, 1. 11  Data  Acquisition — Depending  upon  the  design  phase  in  which 
the  system  effectiveness  evaluation  is  made,  the  sources  of  data  will  differ. 
During  the  definition  phase,  predictions  will  be  based  on  failure  and 
maintenance  rates  derived  from  previous  projects.  Later,  when  more 
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information  becomes  available  from  laboratory  and  field  testing,  the 
predicted  failure  and  maintenance  rates  will  be  suitably  updated. 


3. 5.  5. 1. 12  Equipment  Characteristics --Since  the  prime  purpose  of 
this  example  is  to  illustrate  the  effectiveness  evaluation  procedure,  detailed 
derivations  of  failure  rates  and  repair  rates  will  not  be  given.  The  values 
which  will  be  used  in  this  example  are  listed  in  Table  27.  These  values 
were  taken  from  Reference  15,  Vol.  III. 

3. 5.  5. 1. 13  Determination  of  Availability — Equipment  availability 
using  the  state  space  effectiveness  model  is  determined  in  a  straightforward 
manner  employing  the  basic  model.  In  present  day  work,  availability  is 
usually  calculated  as  the  steady  state  availability: 

_  MTBF 
V  ”  MTBF  +  MTTR 

where 

V  is  the  steady  state  availability  or  state  readiness 
MTBF  is  the  mean  time  between  failures 
MTTR  is  the  mean  time  between  repairs 

Many  objections  have  been  raised  to  this  type  of  approach,  such  as  the 
assumption  of  extremely  long  time  periods  available  for  making  repairs, 
the  assumption  of  allowing  equipment  to  operate  during  the  period  between 
missions,  etc. 


TABLE  27.  AVIONICS  SYSTEM  FAILURE  AND  REPAIR  RATES 


Equipment 

Failure  rate 
fr/hr 

Repair  rate 
rep/hr 

Bombing  radar 

0.0312 

0.167 

Terrain  avoidance  radar 

0.02  50 

0.125 

Toss-bomb  computer 

0.0500 

0.250 

Sight  system 

0.0050 

0.500 

Doppler 

0.0500 

0.067 

Direction  finder 

0.0100 

0.500 

Tacan 

0.0200 

0.250 

Instrument  landing  system 

0.0067 

0.333 

Communications  equipment 

0.0143 

0.  500 

Identification  equipment 

0.0100 

0.333 

Using  the  state  space  effectiveness  formulation,  we  have  a  number  of 
alternatives  available.  We  can  extend  the  time  required  for  maintenance 
and  repair  actions  to  any  arbitrary  length,  simulating  different  mission 
turnaround  times,  or  we  can  make  it  extremely  long,  thus  approaching 
the  steady  state  availability  case.  It  is  also  possible  to  simulate  a 
number  of  sequential  missions  with  the  proper  turnaround  time  and  thus 
obtain  more  accurate  results. 

Let  us  return  now  to  our  illustrative  example.  Referring  to  Figure  30, 
we  will  consider  the  first  subsystem--eommunications.  This  subsystem 
consists  of  the  UHF  transmitter-receiver  and  the  audio  amplifier  combination. 
Its  failure  rate  (referring  to  Table  27)  is  0.0143  fr/hr  and  the  repair  rate 
0.  500  rep/hr.  The  corresponding  state  diagram  becomes: 


.0143 


.500 


In  this  state  diagram  State  1  represents  the  operational  communications 
subsystem.  State  2  the  unoperable  status  of  the  same  subsystem.  Initial 
conditions  on  States  1  and  2  are  determined  as  follows: 

1.  If  we  are  starting  from  the  initial  system  point,  equipment  is 
operating  and  checked  out  at  t  =  0,  then  P^O)  =  1,  PglO)  =  0. 

2.  If  we  are  starting  this  time  phase  at  some  other  point,  say  after 
the  return  from  a  particular  mission,  then  the  corresponding 
probabilities  are  determined  by  the  values  achieved  at  the  end  of 
that  mission. 


If  we  are  interested  only  in  the  steady  state  availability  figures,  it  will 
not  make  any  difference  how  the  initial  conditions  are  selected  provided 
they  add  up  to  unity. 

The  next  subsystem  under  consideration  is  the  IFF.  Here  again  we  find 
a  single,  independent  equipment  configuration.  Its  state  diagram  becomes: 

.0100 

- ► 

E3« -  E4 

.333 

State  3  is  the  IFF  operational  state;  State  4  is  the  IFF  down  state.  Initial 
conditions  again  are  determined  in  the  same  way  as  discussed  earlier. 

Our  next  subsystem,  the  navigation  subsystem,  consists  of  three 
navigational  equipments  essentially  working  in  parallel.  In  this  case  we 
have  three  resulting  equipment  states  for  this  system.  The  following 
nomenclature  will  be  used: 


State 

Doppler 

Tacan 

Direction 

Finder 

E5 

Operating 

Operating 

Operating 

E6 

Operating 

Operating 

Down 

E7 

Operating 

Down 

Operating 

E8 

Down 

Operating 

Operating 

E9 

Operating 

Down 

Down 

E10 

Down 

Operating 

Down 

E11 

Down 

Down 

Operating 

E12 

Down 

Down 

Down 
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The  resulting  state  diagram  is  shown  below: 


An  alternate  formulation  would  be  to  consider  the  three  types  of  equipment 
making  up  the  navigation  subsystem  to  be  independent,  calculate  their 
availabilities  in  the  same  manner  as  we  did  before  in  the  case  of  communica¬ 
tion  and  IFF  subsystems,  and  then  form  the  availability  figures  for  the 
various  states  by  using  the  probability  product  rule.  This  approach  will 
result  in  three  separate  state  diagrams  each  one  having  only  two  arrows, 
but  we  will  have  to  form  eight  product  terms. 


The  bombing  subsystem  also  consists  of  three  parallel  equipment  com¬ 
binations;  however,  the  situation  is  this  case  is  slightly  different.  In  the 
blind  toss  bombing  mode  we  will  require  only  the  bombing  radar  and  toss- 
bomb  computer;  in  visual  toss  mode  we  will  require  only  the  toss-bomb 
computer,  and  for  lay-down  delivery  only  the  sight  system.  Here  again 
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we  have  a  choice  in  our  representation  of  the  existing  requirements. 

Under  the  definitions  stated  above,  it  is  clear  that  the  sight  system  will 
be  modelled  separately,  but  how  about  the  combination  of  bombing  radar 
and  toss-bomb  computer?  Here  two  alternatives  are  available.  One  is 
to  consider  the  bombing  radar  and  the  toss-bomb  computer  separately;  the 
other  approach  involves  modeling  the  combined  toss-bomb  computer  and 
bombing  radar  in  a  single  state  diagram  and  then  setting  up  a  separate 
state  diagram  for  the  toss-bomb  computer  alone.  To  gain  some  experience 
with  the  more  complex  state  diagrams,  we  will  select  the  last  approach 
described  above. 

The  state  diagram  for  the  sight  system  is: 

.005 

e13«—  e14 

.5 


For  the  visual  toss  bombing  mode  we  can  model  the  toss -bomb  computer 
in  a  similar  fashion: 


.05 


E 


15 


.25 


In  the  above  state  diagrams  E^  and  E^,.  represent  the  operating  states 
and  E.  ,  and  E.  „  the  failed  states. 
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For  the  blind  toss  mode  our  state  diagram  will  have  four  distinct  states 
designated  as  follows: 


Radar 

Toss -bomb  Computer 

E17 

Operating 

Operating 

CO 

H 

W 

Operating 

Down 

E19 

Down 

Operating 

E20 

Down 

Down 

The  corresponding  state  diagram  takes  the  following  form: 


The  instrument  landing  (ILS)  and  the  terrain  avoidance  radar  subsystems 
are  single  independent  subsystems.  Their  state  diagrams  are: 


ILS 


.0067 


E 


2U 


.333 


Terrain  avoidance  radar 


.025 


23 


-*•  E 


24 


.125 
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States  21  and  23  are  operational  states,  22  and  24  are  failed  states. 

3. 5.  5. 1. 14  Probability  of  Launch — Under  field  operating  conditions 
launch  is  not  always  ruled  out  just  because  a  particular  equipment  is  not 
ready.  Since  in  many  cases  some  bombing  capability  exists  with  even 
some  inoperative  equipment,  the  probability  of  launch  in  a  degraded  mode 
should  be  considered.  Estimates  for  the  probabilities  of  launch  for  the 
various  equipment  states  are  tabulated  in  Table  28. 

3.5.5.1.15  Determination  of  Capability- -There  is  only  one  more 
parameter  to  be  determined  for  each  functional  equipment  before  we  can 
proceed  with  the  model  exercise. 

Communications  Equipment:  For  the  particular  mission  considered,  the 
communications  function  is  only  required  so  that  specific  target  assignment 
can  be  made  or  changed  after  the  aircraft  has  taken  off.  For  this  example 
it  will  be  further  assumed  that  specific  assignments  will  always  be  made 
while  the  aircraft  is  in  flight.  It  is  estimated  that  in  90  percent  of  the 
cases  specific  target  assignments  can  be  made  before  the  aircraft  is 
out  of  range.  In  the  remaining  10  percent,  an  unsuccessful  mission  will 
result. 

It  is  also  estimated  that  environmental  conditions  and  difficulties  with 
ground  equipment  will  prevent  the  required  communication  5  percent  of  the 
time  when  the  aircraft  is  within  the  operating  range  of  the  base  station. 
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TABLE  28.  PROBABILITIES  OF  LAUNCH 


Equipment 

State 

Probability  of 
Launch 

Communications 

1 

1.0 

2 

0.0 

Identification  (IFF) 

3 

1.0 

4 

0.2 

Navigation 

5 

1.0 

6 

1.0 

7 

1.0 

8 

0.1 

9 

0.8 

10 

0.0 

11 

0.0 

12 

0.0 

Lay-down  delivery  sight  system 

13 

1.0 

14 

0.8 

Visual  toss 

15 

1.0 

Toss-bomb  computer 

16 

0.  7 

Blind  toss 

17 

1.0 

Radar  and  computer 

18 

0.  5 

19 

0.0 

20 

0.0 

Instrument  landing  system 

21 

1.0 

22 

0.95 

Terrain  avoidance  radar 

23 

1.0 

24 

0.0 
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The  capability  of  the  communications  subsystem  is  expressed  as  the 
probability  that  the  target  designation  and/or  change  is  received  and 
acknowledged  by  the  aircraft. 


Thus  in  operational  state  E1 

Cx  =  (0.  90)(0.  95)  =  0.855 

In  the  disabled  communications  state  the  system  capability  is  zero. 

Identification  Equipment  (IFF):  During  the  attack  phase  the  aircraft  is  in 
the  danger  of  being  attacked,  if  it  is  not  able  to  identify  itself  properly, 
and  destroyed  by  friendly  forces.  The  identification  equipment  in  the 
operational  state  has  a  capability  of  unity.  Destruction  of  the  aircraft 
is  not  certain,  however,  even  when  the  identification  subsystem  is  in 
failed  state.  In  this  state  the  aircraft  will  survive  if: 

--It  is  not  challenged,  or 

--It  is  challenged,  but  is  not  destroyed. 

If  we  assume  the  probability  of  challenge  being  0.90  and  the  probability 
of  destruction  0.10,  then 

C4  =  (0.1)  +  (0.9)(0.9)  =  0.91 

Navigation  Equipment:  The  aircraft  must  be  able  to  navigate  to  within 
5  miles  of  the  target  area  by  use  of  the  navigation  equipment;  from  this 
point  target  identification  can  be  accomplished  by  other  means.  On  the 
return  flight  it  must  be  able  to  navigate  to  within  10  miles  of  its  assigned 
base.  While  the  navigation  function  can  be  supplied  by  three  different 
equipments,  the  capability  of  each  is  different.  The  Doppler  equipment 
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has  a  basic  capability  of  0.95,  the  Tacan  of  0.9,  and  the  direction  finder 
(DF)  of  0.8.  However,  because  the  Tacan  and  DF  equipments  require 
external  signals  from  associated  ground  stations,  the  probabilities  that 
these  signals  will  be  available  must  be  considered.  While  the  Doppler 
can  be  used  at  any  time  it  is  operating  properly,  the  Tacan  ground  station 
will  be  available  only  50  percent  of  the  time  and  DF  ground  station  only 
40  percent  of  the  time. 

The  actual  capabilities  for  each  equipment  are: 

C,  ,  =0.95 

doppler 

Ctacan  =  <0. 9)(0.  5)  =  0. 45 
=  (0.8K0.4)  =  0.32 

Next,  we  must  consider  the  capabilities  for  the  eight  distinct  states  of  the 
navigation  subsystem.  The  capability  of  each  state  will  be  the  capability 
of  the  operating  equipment  whose  individual  capability  is  the  highest,  if 
all  equipments  are  equally  available.  In  the  case  of  the  state  in  which 
both  the  Tacan  and  DF  equipment  are  available,  but  the  Doppler  has  failed 
(E„),  the  probabilities  that  the  ground  stations  for  Tacan  and  DF  will  be 

O 

available  must  also  be  considered.  Assuming  independence  between  the 
Tacan  and  DF  ground  stations,  the  capability  in  this  state  is: 

CQ  =  (Probability  that  Tacan  can  be  usedKTacan  capability)  + 

O 

(Probability  that  only  DF  can  be  used)(DF  capability)  = 

=  (0.  5)(0. 9)  +  (1.0  -  0.  5)(0. 4)(0. 8)  =  0.61 
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Target  identification  and  weapon  delivery  equipment:  The  target  can  be 
identified  either  visually  or  by  means  of  the  radar  equipment.  The  ability 
to  deliver  a  weapon  within  500  feet  of  an  identified  target  is  dependent  upon 
the  mode  of  the  delivery.  For  the  particular  example  these  probabilities 
are  estimated  or  based  on  previous  experience. 

Instrument  landing  equipment  (ILS):  The  instrument  landing  system  when 
functioning  properly  has  a  capability  of  0.  99.  That  is,  a  landing  without 
damage  to  the  aircraft  or  injury  to  the  pilot  can  be  made  99  times  out  of 
100.  In  weather  during  which  this  equipment  is  not  required,  the  probability 
of  successful  landing  is  1.0. 

If  we  assume  that  visual  landing  procedures  are  possible  95  percent  of  the 
time,  the  probability  of  successful  landing  if  the  ILS  is  operable  is: 

C2i  =  (Probability  of  visual  ianding)(Probability  of  successful 
landing  under  visual  conditions)  +  (Probability  of  ILS 
landing)  (Probability  of  successful  landing  under  ILS 
conditions) 

=  (0.95)(1.0)  +  (0.05)(0.  99) 

=  0.9995 

If  the  ILS  is  not  operable,  no  capability  under  ILS  conditions  exist,  and 
the  overall  landing  capability  is  0.95. 

Terrain  avoidance  equipment:  The  terrain  avoidance  function  of  the  radar 
is  the  only  avionics  equipment  that  contributes  to  the  penetration  ability 
of  the  aircraft.  This  equipment  permits  flying  the  aircraft  at  normal 
attack  speeds  at  low  altitudes,  that  is,  below  1000  feet.  Without  this 
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equipment,  such  low  level  approaches  are  not  possible.  If  we  assume 
that  the  anticipated  losses  due  to  enemy  action  are  5  percent  for  low 
altitude  approaches  and  30  percent  for  high  altitude  approaches  and  that 
the  atmospheric  conditions  which  result  in  improper  radar  returns  are 
anticipated  1  percent  of  the  time,  the  penetration  capabilities  (the 
probability  of  penetrating  enemy  defenses),  when  the  enemy  action 
effectiveness  is  considered,  are: 

C„„  =  (Probability  that  radar  permits  low  approach) (Probability 
of  survival,  given  low  approach)  +  (Probability  radar 
does  not  permit  low  approach )(probability  of  survival, 
given  high  approach) 

«  (0.99)(0.05)  +  (0.  01)(0.  70) 

=  .9475 

C24  =  Probability  of  survival,  given  high  approach 
=  0.70 

A  summary  of  the  state  capabilities  is  given  in  Table  29. 

3. 5. 5.2  Model  Exercise — In  the  previous  subsections  we  have  derived  all  the 
pertinent  state  diagrams  for  the  individual  subsystems.  Our  next  task  is 
to  compute  the  subsystem  availability  numbers.  Assume  that  for  our 
example  we  elect  to  calculate  the  steady  state  availabilities.  Then  we  can 
establish  as  the  input  to  the  SESIP  eight  independent  state  diagrams  with 
their  corresponding  transition  arrows  (repair  and  failure  rates).  Assuming 
that  we  start  with  all  equipment  operational  at  time  t  =  0,  initial  conditions 
of  unity  are  introduced  in  states  1,  3,  5,  13,  15,  17,  21,  23;  initial  con¬ 
ditions  on  all  other  states  are  equal  to  zero. 


TABLE  29.  STATE  CAPABILITIES  (SUMMARY) 


Equipment 

State 

Capability 

Communications 

1 

0.855 

2 

0.000 

Identification 

i/ 

1.000 

4 

0.910 

Navigation 

5 

0.950 

6 

0.  950 

7 

0.950 

8 

0.610 

9 

0.950 

10 

0.450 

11 

0.320 

12 

0.000 

Lay- down  delivery 

13 

0.  900 

Sight  system 

14 

0.700 

Visual  toss 

15 

0.800 

Toss -bomb  computer 

16 

0.600 

Blind  toss 

17 

0.750 

Radar  and  computer 

18 

0.400 

19 

0.000 

20 

0.000 

Instrument  landing  system 

21 

0.  9995 

22 

0.950 

Terrain  avoidance  radar 


23 

24 


0.9475 

0.700 


Next,  we  select  the  first  time  phase.  In  our  example  1000  hour  operation 
will  be  sufficient  to  establish  the  steady  state  conditions.  At  the  end  of 
1000  hour,  time  increment  probabilities  associated  with  each  state  will  be 
the  desired  availability  figures.  If  we  multiply  these  probabilities  by  the 
probabilities  of  launch  (given  in  Table  28),  the  necessary  initial  conditions 
for  the  mission  are  established.  In  the  next  step  we  will  remove  all  arrows 
associated  with  repair  actions  (there  is  no  in-flight  repair  capability 
considered  in  this  example)  and  those  arrows  associated  with  deenergized 
equipment  during  the  first  mission  phase. 

Examining  the  mission  profile  and  equipment  usage  chart  (Figure  31),  we 
can  select  the  necessary  mission  phases.  In  our  example  we  select 
0.4,  0.7,  and  0.9  hours  as  intermediate  points.  At  time  t  =  0  hours  we 
deenergize  terrain  avoidance  and  bombing  radar  and  the  toss -bomb 
computer.  At  0.4  hours  we  energize  the  terrain  avoidance  and  bombing 
radar  and  the  toss-bomb  computer  and  deenergize  the  communications 
subsystem.  At  0.7  hours  we  deenergize  the  toss-bomb  computer;  0.1 
hours  later,  at  0.  8  hours  we  deenergize  the  terrain  avoidance  and  bombing 
radar.  At  0.9  hours  the  ILS  subsystem  is  energized  (This  subsystem  was 
deenergized  at  t  =  0  hours).  At  1.2  hours  we  stop  our  simulation. 

At  this  point  we  have  all  the  required  probabilities  associated  with  being 
in  a  given  state  at  the  end  of  the  mission  and  now  we  can  apply  the  proper 
capability  coefficients  (Table  29).  Summing  the  products  (state  probability 
times  state  capability)  for  each  state  diagram,  we  can  determine  the 
subsystem  effectiveness  values. 
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3. 5. 5.2.1  Effectiveness  for  Individual  Mission  Types--The 
individual  functional  effectiveness  figures  may  now  be  combined  to  evaluate 
the  system  effectiveness  for  each  mission  type.  Using  the  conventional 
approach  (assuming  that  subsystems  are  independent  and  that  their 
effectivenesses  can  be  combined  using  the  product  rule),  we  form  product 
terms  containing  all  those  subsystem  effectiveness  numbers  which  are 
necessary  for  completing  a  specific  mission. 

In  our  example,  communications,  identification,  navigation,  landing,  and 
penetration  subsystems  are  common  to  all  mission  types.  They  differ  only 
in  the  equipment  necessary  to  complete  a  specific  delivery.  Thus  we  can 
combine  states  1-12  and  21  -  24  in  the  common  group  and  work  with 
states  13-14  for  lay-down  delivery,  15-16  for  visual  toss  mode,  and 
17-20  for  blind  toss  mode. 


Communication:  The  effectiveness  attributes  for  the  two  communication 
states  (Ej,  Eg)  are  summarized  as  follows: 

Availability  (A)  =  [0.972  .0028] 

r  n 


Probability  of 
Launch  (U) 


0 


0 


Dependability 


.9943  0.0057 

0  1.0 
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Capability  (C) 


0.855 

0 


Effectiveness  of  the  communication  subsystem  is  computed  from  the  product 
E  =  A  .  U  .  D  .  C 
Ec  =  0.826323 


Identification:  The  effectiveness  attributes  for  the  two  IFF  states  (Eg.  E^) 
are  summarized  as  follows: 

A  =  [0.971  0.029] 

'1.0 


U  = 


D  = 


C  ■ 


0 

0  0.2 

0.9881  0.0119 


0 

1.0 


1.0 


Id.  91 J 

Effectiveness  of  the  identification  subsystem  is  computed  from  the  product 
E  =  A  .  U  .  D  .  C 

El  = 


0.975238 


Navigation:  The  effectiveness  attributes  for  the  eight  navigation  states 

(Ec  -  Ei0)  are  summarized  as  follows: 
o  12 


A  =  [0.518,  0.011,  0.041,  0.001,  0.389,  0.031,  0.001] 


U  = 


1.0 

1.0 

1.0 

0.8 

0.1 

0.0 

0.0 

0.0 


0.9085 

0.0109 

0.0220 

0.0561 

0.0003 

0.0007 

0.0014 

0. 

0.9195 

0. 

0. 

0.0223 

0.0568 

0. 

0. 

0. 

0.9306 

0. 

0.0112 

0. 

0.0575 

0. 

0. 

0. 

0.9418 

0. 

0. 

0. 

0. 

0. 

0. 

0. 

0.9647 

0.0116 

0.0234 

0. 

0. 

0. 

0. 

0. 

0.9763 

0.9763 

0. 

0. 

0. 

0. 

0. 

0. 

0.9881 

0. 

0. 

0. 

0. 

0. 

0. 

0. 

0.95 

0.95 

0.95 

0.95 

0.61 

0.45 

0.32 

0.0 


Effectiveness  of  the  navigation  subsystem  is  computed  from  the  product 


E  =  A  .  U  .  D  .  C 


E  =  0.56278298 
n 


0.00 

-0014 

-0007 

0.0582 

0.0003 

0.0237 

0.0019 

1.0 
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Penetration:  The  effectiveness  attributes  for  the  two  penetration  states, 
with  or  without  the  terrain  avoidance  radar,  (Egg.  Eg^)  31,6  summarized 
as  follows: 


A  =  [0.833  0.167] 


Effectiveness  of  the  penetration  subsystem  is  computed  from  the  product 

E  =  A  .  U  .  D  .  C 

E  =  0.787206 
P 

Landing:  The  effectiveness  attributes  for  the  two  landing  states,  with  or 
without  the  instrument  landing  system,  (Eg^,  Egg)  are  summarized  as 
follows: 


D  = 


C  = 


0.998  0.002 

0  1.0 

- 

-  - 
0.9995 

0.95 


Effectiveness  of  the  landing  subsystem  is  computed  from  the  product 


E  ■  A  .  U  .  D  .  C 

Et  =  0.981218 
Lj 


Lay-dovm  mode  (weapon  delivery):  The  effectiveness  attributes  for  the 

two  states  (E.-,  E  )  of  the  sight  subsystem  used  are  summarized  as 
X  o 

follows: 


[0.990 

0.010] 

1.0 

0 

0 

0.8 

0.999 

O.OOll 

0 

1.0 

J 

Effectiveness  of  the  lay-down  mode  subsystem  is  computed  from  the  product 
E  =  A  .  U  .  D  .  C 
E1  =  0.896402 
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Visual  toss  mode:  The  effectiveness  attributes  for  the  two  states  (E,c, 

15 

E^g)  of  the  toss  bomb  computer  used  are  summarized  as  follows: 


A 

U 


D 


C 


[0.833  0.167] 

1.0  o.o' 

_  0  0.7 

0.9851  0.0149 

0  1.0 

0.80 

0.60 


Effectiveness  of  the  visual  toss  mode  subsystem  is  computed  from  the  product 


E  =  A  .  U  .  D  .  C 

E  =  0.7340576 
v 


Blind  toss  mode:  The  effectiveness  attributes  for  the  four  states  (E17-E9n) 

Xi 

of  the  toss-bomb  computer  and  bombing  radar  used  for  this  function  are 
summarized  as  follows: 


A  =  [0.701  0.141  0.132 


0.026} 
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D 


0.11729 

0 

0 

0 


0.1047  0.0122 

0.9876  0 

0  0.9851 

0  0 


0.0002 

0.0124 

0.0149 

1 


0.75 

0.40 

0.0 

0.0 


Effectiveness  of  the  blind  toss  mode  subsystem  is  computed  from  the  product 

E  =  A  .  U  .  D  .  C 

E.  ■  0.543475 
b 


3.  5.  5.2.2  Overall  System  Effectiveness- -A  single,  overall  system 
effectiveness  figure  may  be  obtained  from 


E  =  E.  .  P.  .  +  E  ,P  .  +  E.  .P.  , 
Id  Id  vt  vt  bt  bt 


where  the  subscripts  denote  the  type  of  mission, 

E  refers  to  mission  effectiveness 

P  is  the  probability  that  a  particular  type  mission  will  be  flown. 


Pj^  (Probability  of  lay-down  delivery)  =  (Probability  of  daytime  mission) 
(Probability  of  good  weather  conditions)(Probability  that  lay-down 
delivery  is  preferred)  =  (.  58)(.  8)(.  8)  =  .3712 

P  ^  (Probability  of  visual  toss  delivery)  =  (Probability  of  daytime  mission) 
(Probability  of  good  weather  conditions )(Probability  that  toss  bombing 
is  preferred)  =  (.  58)(.8)(.2)  =  0.0928 
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pbt  (Probability  of  blind  toss  delivery)  =  (Probability  of  night  mission)  + 
(Probability  of  bad  weather  condition)  -  (Probability  of  night  mission 
and  bad  weather  conditions)  =  .  42  +  .2  -  (.42)(.2)  =  .536 

Substituting  the  mission  effectiveness  values  in  the  above  expression,  we 
will  obtain  the  overall  expected  mission  effectiveness  figure. 

The  individual  functional  effectiveness  figures  can  now  be  combined  to 
evaluate  the  system  effectiveness  in  each  of  the  modes  of  mission  for 
lay-down  mode,  visual  toss  mode,  and  blind  toss  mode. 

Lay-down  delivery  mode:  (Ej) 

E1(J  =  [Ec  X  E(  X  EpJ  x  EL  X  EpJ  X  E, 

=  [(.826)  x  (.975)  x  (.553)  x  (.991)  x  (.787)]  x  [.8964] 

=  [.347]  x  [0.8964] 

■  0.31 

Visual  toss  mode: 

Evt  =  1ECXEIXENXELX  VxEv 
=  [0.347]  x  [0.7340] 

=  .25 
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Blind  toss  mode: 


Ebt  =  lECxEIxENxELxEp]XEb 
=  [0.347]  x  [0.5435] 

=  .19 


The  single,  overall  system  effectiveness  is  computed  irom: 

E  =  E.  ,  P.  ,  +  E  .  P  t  +  E.  t  P.  t 
Id  Id  vt  vt  bt  bt 

=  0.31  x  .3712  +0.25  x  0.0928  +  0.19  x  0.536 

=  0.115  +  0.023  +  0.102  =  0.24 


3.  5.  5. 3  Survivability  Considerations- -Including  survivability  in  the 
effectiveness  evaluation  adds  another  matrix  in  the  effectiveness  calculation. 
For  example,  the  effectiveness  attributes  for  the  eight  navigation  states 
would  include  availability  (A),  probability  of  launch  (U),  dependability 
(D),  survivability  (S),  and  capability  (C).  Effectiveness  of  the  navigation 
subsystem  is  then  computed  from  the  product 

E  =  A  .  U  .  D  .  S  .  C 
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•where 


The  development  of  the  S- matrix  is  given  below.  No  quantitative  values 
were  available  for  this  example.  However,  the  product  is  straightforward 
and  can  be  implemented  in  the  SESIP  program. 

3.  5. 5. 4  Survivability  Analysis  Example- -Survivability  is  the  capability 
to  be  shot  up  without  being  shot  down.  Survivability  is  designed  into  a 
system  in  several  ways: 

•  Dispersing  equipments  that  have  the  same  or  similar  functions 
(so  no  shot  takes  out  two  or  more) 

•  Replicating  (and  dispersing)  equipments  whose  function  is  vital 
(Replication  is  done  for  dependability  anyway. ) 

•  Shielding  equipment  by  placing  it  behind  some  relatively  massive 
part  of  the  airplane  in  relation  to  the  direction  of  the  major 
threat. 
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•  Hardening  equipment  (expensive  in  terms  of  weight) 

•  Clustering  essential  (but  small)  components  in  one  place 
so  that  they  share  vulnerable  space 

3. 5.  5. 4.1  Survivability  Analysis  of  Navigation  States — Major  sub¬ 
systems  (individual  equipments  are  all  independent)  are  listed  with 
identifying  acronyms  of  all  equipment  used  for  navigation  functions. 


a. 

Fire  Control 

b. 

Doppler  Navigation 

DOP 

c. 

Comrr  uy.icatii  ii- Identification-Navigation  (CIN) 

UHF  Direction  Finder 

UDF 

Tacan 

TAC 

Instrument  Landing  System 

ILS 

UHF  Transmitter-Receiver 

UTR 

Identification  Equipment 

ID 

Audio  Amplifier 

AUD 

Notation 

Boolean  AND  * 

Boolean  OR  9 


The  functions  performed  by  the  equipments  in  subsystems  b  and  c  are 
designated  by  the  acronyms. 
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Multiplication  (usually  of  probabilities)  • 

Addition  (usually  of  probabilities)  + 

S  (DOP)  A  survival  probability  of  the  DOP  function 

P  (DOP)  4  kill  probability  of  the  DOP  function 
ditto  for  all  other  functions 

S  =  1  -  P  (survival  probability) 

A  superbar  denotes  NOT  (NOT  A  =  A) 

The  P  (equipment)  is  zero  during  a  mission  until  one  gets  shot  at.  P  grows 
with  time  during  the  shooting  phase,  so  that  S  decreases  with  time  during 
this  phase.  The  first  objective  is  to  relate  the  S's  of  equipments  to  the 
S's  of  subsystem  functions. 

The  functions  performed  by  the  equipments  in  subsystems  b  and  c  are: 


Receive  (requires  both  UTR  and  AUD)  RX 

Identify  self  (requires  both  UTR  and  ID)  IFF 

Doppler  navigation  NV1 

Tacan  navigation  (requires  ground  station  and 

acceptably  small  range)  NV2 

Direction  finder  navigation  (requires  ground 

station  and  acceptably  small  range)  NV3  >2 


Some  auxiliary  variables 

Tacan  ground  stations  GDT 

Within  Tacan  range 


RT 


UDF  ground  station 
Within  UDF  range 


GDD 


RD 


Boolean  statements  for  survival  of  subsystem  functions,  assuming 
individual  equipments  are  dispersed,  are: 


RX  =  UTR  *  AUD  (3) 

IFF  =  UTR  *  ID  (4) 

NV1  «  DOP  (5) 

NV2  =  TAC  *  GDT  *  RT  (6) 

NV3  =  UDF  *  GDD  *  RD  (7) 


3,  5.  5. 4.2  Navigation  Functions  and  Navigation  States — The  three 
navigation  functions  have  states  of  working  or  not  working  (  1  or  0).  The 
various  combinations  of  states  of  navigation  functions  make  up  eight  states 
of  the  navigations  system.  To  evaluate  survival  probabilities  of  a 
navigation  state,  one  must  first  evaluate  survival  probabilities  of  states 
of  navigation  functions. 

How  does  equipment  configuration  affect  states  of  navigation  functions? 
Suppose  TAC  and  UDF  are  packaged  together  so  that  a  hit  on  their  box 
takes  out  both  equipment  functions.  Then  the  second  and  third  navigation 
survival  functions  are: 

NV2A  =  TACUDF  *  GDT  *  RT  (8) 

NV3A  =  TACUDF  *  GDD  *  RD,  (9) 
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where  the  function  TACUDF  is  what  happens  when  the  box  gets  hit.  Through¬ 
out  the  shooting  phase  each  box  accumulates  some  kill  probability.  The 
events  of  killing  the  second  navigations  functions  are 

NV2  =  TAC  ®  GDT  0  RT-  (10) 

and 

NV2A  =  TACUDF  ©GDT  +  RT"  (11) 

Since  TACUDF  is  a  bigger  box  than  TAC.  TACUDF  has  a  higher  kill 
probability; 

P  (TACUDF)  =  Probability  of  TACUDF  (12) 

and 

P  (TACUDF)  >  P  (TAC)  (13) 

The  probability  of  losing  the  function  NV2  is 

P  (NV2)  =  Probability  of  NV2  (14) 

■  P(TAC)  +  P  (GDT)  +  P(RT)  (15) 

-  P(TAC)  P(GDT)  -  P(TAC)  P(RT)  -  P(GDT)  P(RT) 

+  P(TAC)  P(GDT)  P(RT) 

Define 

P(NV2A)  =  Probability  of  NV2A 
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P(NV2A)  is  the  same  as  (15)  with  P(NV2A)  replacing  P(NV2).  The  terms 
without  products  (first  three)  are  the  most  important  because  probabilities 
are  always  less  than  1  and  products  become  small. 

The  same  treatment  applies  for  NV3  and  NV3A. 

Result:  Common  packaging  will  increase  kill  probability  of  individual 
equipment  functions  and  reduce  success  probability  of  navigation  functions. 

3. 5.  5. 4. 3  Communications,  Functions  and  States--UTR  is  required 
for  both  communications  functions  (3)  and  (4).  Communication  states  are: 

Receive  and  identify 

Receive  or  identify 

Neither 

The  receive  and  identify  state's  dependence  on  equipment  functions  is 
RX  *  IFF  =  (UTR  *AUD)  *  (UTR  *  ID)  (16) 

=  UTR  *  AUD  *  ED, 
and  the  survival  probability  is 

S  (RX  *  IFF)  =  S(UTR)  *  S(AUD)  *  S(ID)  (17) 

Now  consider  a  second  transceiver  (UTRA)  separated  from  the  first  one 
and  operable  for  both  RX  and  IFF  functions.  The  receive  and  identify 
state's  dependence  on  equipment  functions  now  is 

(RXA  *  IFFA)  =  (UTR  +  UTR)  *  AUD  *  ID  (18) 


l 


Now  compare  success  probabilities  of  (17)  and  (18).  Before  the  first  shot 
hits,  all  boxes  have  S=l.  Then 

S(RX  *  IFF)  =  l3  =  1 

and 

S(RXA  *  IFF)  =  S(UTR)  S(AUD)  S(ID) 

+  S(UTRA)  S(AUD)  S(ID) 

-  S(UTRA)  S(UTR)  S(AUD)  S(ID)  (19) 

=  2  (l3)  -  l4  =  1 

The  second  transceiver  does  not  contribute  to  survivability  when  there  has 
been  no  threat  to  component  survival. 

Now  assume  we  are  into  the  shooting  phase  to  the  point  where  each  box  has 
a  survival  probability  of  0.5.  Then  (17)  and  (18)  are 

S(RX  *  IFF)  =  (1/2)3  =  1/8  (20) 

and 

S(RXA  *  IFF  A)  =  (1/2)3  +  (1/2)3  -  (1/2)4  =  3/16 

There  is  now  a  healthy  increase  (50  percent  at  this  point  in  the  mission) 
in  success  probability  of  the  state  receive  and  identify  from  duplicating 
the  UTR  function. 

In  the  second  communication  state, 

RX  ®  IFF  =  UTR  *  AUD  0  UTR  *  ID  (21) 


UTR  *  (AUD  +  ID) 


The  survival  probability  of  the  second  communication  state  (receive  or 
identify) 


S(RX  ©  IFF)  =  S(UTR)  S(AUD)  +  S(UTR)  S(ID)  (22) 

-  S(UTR)  S(AUD)  S(ID) 

Also,  adding  the  second  transceiver 

RXA  ©  IFFA  =  (UTR  ©  UTRA)  *  AUD 
+  (UTR  ©  UTRA)  *  ID 
=  (UTR  ©  UTRA)  *  (AUD  ©  ID) 

=  UTR  *  (AUD  ©  ID)  +  UTRI  *  (AUD  ©  ID)  (23) 

and  the  survival  probability  for  the  state  of  receive  or  identify  with  the 
transceiver  is 

S(RXA  ©  IFFA) 

=  S(UTR)  S(AUD)  +  S(UTR)  S(ID)  -  S(UTR)  S(AUD)  S(ID) 

+  S(UTRA)  S(AUD)  +S(UTRA)  S(ID)  -  S(UTRA)  S(AUD)  S(ID) 
-  S(UTR)  S(UTRA)  S(AUD)  -  S(UTR)  S(UTRA’  S*ID)  '24) 
+  S(UTR)  S(UTRA)  S(AUD)  S(ID) 

When  all  S’s  are  1,  (22)  and  (24)  are  both  1,  But  when  all  S's  are  1/2, 
(22)  is 

S(RX  0  IFF)  =  2(1/4) -(1/3)  =  3/8  (25) 

and  (24)  is 

S(RXA  ©  IFF)  =  4(1/4)  -  4(1/8)  +  1/16  =  7/16 
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After  the  probability  of  success  of  every  individual  box  is  reduced  to  1/2, 
the  success  probability  of  the  state  receive  or  identify  is  16  percent 
higher  if  the  UTR  box  is  duplicated.  Note  also  that  the  state  receive  or 
identify  has  much  higher  survival  probability  than  the  state  receive  and 
identify  at  the  same  stage  in  the  mission  (compare  (25)  with  (20)). 

3.5.  5.4.4  Navigation  States--Navigation  states  are  eight  combinations 
of  the  three  navigation  functions  working  and  not  working.  Since  the 
functions  are  independent,  state  probabilities  are  products  of  function 
probabilities.  For  example,  the  survival  probability  for  navigation  state 
is 

S(Nj)  =  S(DOP)  S(NV2)  S(NV3) 

Before  proceeding,  shorten  notation  by  defining 

Sx  -  S(DOP) 

52  =  S(NV2) 

53  =  S(NV3) 

3. 5.  5.4.  5  Function  States  and  Probabilities — We  assume  no  repair 
capability,  so  that  any  function  in  its  0  state  remains  there  with  probability 
1.  Any  function  working  at  the  beginning  of  a  threat  encounter  is 
accumulating  kill  probability  (in  a  software  analysis  of  the  encounter),  so 

P^  is  monotone  nondecreasing  (and  usually  increasing) 

(Pj  starts  at  0) 
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Therefore 


is  monotone  nonincreasing  (and  usually  decreasing) 

Sj  starts  at  1  since  Sj  =  1-P^ 

Without  repair  capability,  a  function  cannot  make  a  transition  from  its  0 
state  to  its  1  state. 


As  an  example,  consider  transitions  between  states  Nj  and  Ng. 

DOP  TAC  DF 

Nj  111 

n2  110 

Denote  elements  of  the  survivability  matrix  by  S^.. 


The  elements  that  relate  states  and  N2  are: 


Sjj  =  Sj  S2  S3  =  probability  of  all  three  navigation  functions 

surviving 


S22  =  S2  1  3  probability  of  functions  1  and  2  surviving  and 

function  3  remaining  in  0  state 


^12  =  S1  S2  ^"^3)  Probability  of  functions  1  and  2  surviving  and 
=  S.,  S„  P„  function  3  not  surviving 

\  Ct  J 

S2i  3  Sj  S2  0=0  because  DF  cannot  repair  itself 


205 


Inspection  of  the  navigation  state  table  then  shows  that 


Sy  =  o,  i  >  j  i.  j 

because  0  to  1  transitions  would  occur.  There  are  some  terms  above  the 
matrix  diagonal  that  are  0  for  the  same  reason. 

The  remaining  diagonal  terms  are: 

S33  "  S1  S3 
S44  =  S1 
S55  =  S2  S3 


Transitions  by  degraded  performance  due  to  damage  have  the  probabilities: 


N1  N2 

S12 

= 

S1  S2  =  S1 

S2P3 

N1  N3 

S13 

= 

S1  <1-S2>S3  =  S1 

P2S3 

N,  -»  N„ 

1  4 

S14 

= 

Sj  (1-S2) (1-S3)  = 

S1  P2  P3 

Nl-N5 

S15 

= 

<1-S1)  S2  S3  =  P1 

S2  S3 

Nl"N6 

S16 

= 

(l-s^  S2  (1-S3)  ■ 

P1  S2  P3 

ni-n? 

S17 

= 

(1-Sj)  (1-S2)  S3  = 

P1  P2  S3 

ni-n8 

S18 

= 

(1-Sj)  (i-s2)  (i-s3 

>  =  P!  P2  P3 
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N2**N3 


0  (requires  repair  of  DF  state) 


N2  N4  S24  =  Sl(1-S2}  =  S1P2 

N„  -*  N_  Soc  0  (requires  repair  of  DF  state) 

C  5  £  D 

N2  **  N6  S26  "  ^“S1^S2  ~  P1  S2 

N„  -»  N„  S__  =  0  (requires  repair  of  DF  state) 

Ct  (  o  ( 

N2  -  N8  S28  =  <1‘S1)  <1"S2)  *  P1  P2 


n3-n4 


N3^N5 

N3^N6 

N3-N7 

N3^N8 


N4-N5 

N4*N6 
N4  "*N7 


N4  "*N8 


N5"N6 

n5^n7 

N5"N8 


s34  *  St  (1-S3)  •  Sl  P3 

S„,  =0  (requires  repair  of  Tacan  state) 

o  D 

536  =  °  (requires  repair  of  Tacan  state) 

537  '  «-Sl>  S3  *  P1  S3 

s38  -  (1-Sj)  (1-S3)  -  P,  p3 

^45  =  °  ^re<lu^res  rePair  °f  Tacan  state) 

S4g  =  0  (requires  repair  of  Tacan  state) 

S47  =  0  (requires  repair  of  DF  state) 

s48  -  d-s,)  -  p1 

556  =  S2  <1“S3>  *  S2  P3 

557  =  (1"S2>  S3  =  P2  S3 

558  =  (1-S2)  <1‘S3>  =  P2  P3 
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N6  N7 
N6  "N8 

N?  -»Ng  S?8  -  1-Sg  -  Pg 

The  survivability  matrix  for  the  eight  navigation  states  is  now  seen  to  have 
the  form: 


S11  S12 

S13 

S14 

S15 

S16 

S17 

CO 

H 

xn 

S22 

0 

S24 

0 

S26 

0 

S28 

S33 

S34 

0 

0 

S37 

S38 

S44 

0 

0 

0 

S48 

S55 

S56 

S57 

S58 

S66 

0 

S68 

S77  S78 
1 


The  significant  fact  about  the  form  of  the  survivability  matrix  is  that  two 
thirds  of  its  elements  above  the  diagonal  are  non  zero.  The  values  of  the 
non- zero  entries  will  depend  strongly  on  the  intensity  of  the  threat 
encountered. 

3.6  SYSTEM  SELECTION/OPTIMIZATION  PROCESS 
3.6.1.  Background 


Sg7  =  0  (requires  repair  of  DF  state) 


S68  =  1-S2  =  P2 


In  the  event  that  more  than  one  control -of -flight  system  candidates  equal 
or  exceed  the  effectiveness  goal  for  the  mission(s)  and  stay  within  the  cost 


constraints  for  the  system,  a  selection  process  is  required  to  determine 
an  optimal  system.  This  optimal  system  selection  must  be  based  on 
criteria  involving  some  combination  of  effectiveness  and  cost  measures. 

This  criterion  is  referred  to  as  a  measure  of  worth  or  a  utility  measure. 

The  technique  used  to  perform  this  selection /optimization  step  of  the  ICDT 
design  methodology  requires  an  application  of  linear  programming.  Usually 
linear  programming  problems  are  solved  by  a  recursive  method  called 
the  Simplex  method.  Honeywell  has  a  modified  Simplex  program  called 
ALPS  which  stands  for  advanced  linear  programming  system  and  it  has  the 
practical  capability  of  solving  problems  that  have  up  to  850  constraints. 
Almost  any  computerized  Simplex  method,  however,  will  handle  enough 
constraints  to  solve  the  ICDT  system  selection/optimization  problem. 

In  essence  this  linear  programming  technique  is  used  to  determine  values 
of  the  designer /customer  selected  utility  measure  for  each  system  candidate 
that  has  passed  the  defined  thresholds  established  for  cost  and  effectiveness. 
The  utility  criteria  should  be  selected  during  the  problem  definition,  step 
1,  along  with  the  threshold  constraints  on  cost  and  effectiveness.  For  the 
ICDT  problem,  utility  measures  such  as  the  minimized  cost  for  a  constrained 
value  of  effectiveness  or  the  maximized  effectiveness  for  a  constrained 
value  of  cost  might  be  appropriate. 
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To  illustrate  the  application  of  the  selection/optimization  process,  an 
example  is  presented  that  shows  how  the  optimized  selection  can  be  affected 
by  the  choice  of  the  utility  measures  (or  measure  of  worth)  to  be  optimized. 
This  problem  involves  the  selection  of  a  mix  of  candidate  solutions  to  meet 
a  set  of  effectiveness  measures  rather  than  the  selection  of  only  one  system. 
The  principles  of  the  selection  process  are  the  same  for  either  case,  however, 
and  are  well  illustrated  in  this  example. 


3.6.2  Illustrative  Example 


Six  rather  standard  measure  of  worth  models  are  described  below.  These 
models  are  useful  for  problems  in  which  an  optimal  mix  of  systems  is  to  be 
found  to  satisfy  specific  objectives. 


Measure  I: 


Measure  II: 


Measure  III: 


-  T  - 

Minimize  cost  (Z  =  C  .X)  subject  to  minimum  and 
maximum  performance  vector  constraint  (bs  P  £  a) 


M 

Maximize  overall  mix  performance  (Z  =  5 

3=1 


Pj)  subject 


to  a  mix  cost  constraint  and  minimum  and  maximum 
performance  constraints  (b  £  P  *  a  and  CTX  £  K) 


-  T-  1 

Maximize  relevant  normalized  performance  (Z  =  R  P  ), 
where  P^  represents  the  performance  vector  normalized 
by  division  of  each  component  by  its  maximum  value, 
subject  to  cost,  minimum  performance,  and  maximum 
performance  constraints  (cTxC,  bs  psa) 
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Measure  IV: 


Measure  V: 


Measure  VI: 


-T- 

Minimize  cost  (Z  *  c  x)  subject  to  minimum  and 
maximum  performance  accomplishment  (b  *  P  £  a) 
and  also  minimum  relevant  normalized  performance 

-  t  -1 

(R  P  *  d) 


Maximize  the  multipurpose  performance  capability 
-  t- 

(Z  =  E  X)  subject  to  the  usual  cost,  minimum,  and 

maximum  performance  capability  constraints.  The 

1  M 

vector  E  has  components  =  —  5  e^  i=l,2, — 

N  which  represents  the  average  unrf  of  effectiveness 
of  the  i^1  avionics  system  Ai. 


Maximize  the  relevant  multipurpose  performance 
-  T- 

capability  (Z  =  E_.  X)  subject  to  cost,  minimum  and 
H  _ 

maximum  performance  constraints  (e  x  £  C,  b  £ 

P  £  a)  where  the  vector  E_.  represents  the  average 

K 

weighted  unit  effectiveness  with  the  weights  set  to 
the  ratio  of  priority  to  maximum  performance  level 

(R3/PjMAX);  3=1'  2'  Mf 


The  symbolic  notation  used  above  is  defined  as  follows: 

Z  =  the  objective  functional  (linear) 

-T  N  M 

C  =  C  .  X  =  5  y  C.  x.  .  =  total  mix  cost 
i=l  j=l  1  13 

N  =  number  of  system  candidates 
M  =  specific  objectives  of  mission 
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number  of  systems  A.  allocated  toward  accomplishment 

til  * 

of  the  j  specific  objective 

the  allocation  mix,  an  N  x  M  matrix  array 


xll* 

X12  -  “ 

Xij 

X1M 

Xil' 

Xi2  *  - 

tx 

Ut. 

1 

1 

XiM 

XN1' 

1 

1 

CM 

XNj  '  - 

XNM 

th 

unit  cost  of  the  i  system  A^ 

th 

performance  of  the  j  objective 

ttl 

priority  ranking  of  the  j  objective 

component  of  a  constraint  vector  a 

component  of  a  constraint  vector  b 

th  th 

unit  effectiveness  of  i  systems  against  j  objective. 


SECTION  4 


ICDT  DEMONSTRATION  PROGRAM 


The  general  procedure  for  designing  the  non-data  processing  system  was 
described  in  Section  3.4.2.  To  show  that  ICDT  methodology  is  a  viable 
approach  and  that  it  works,  a  demonstration  program  was  developed 
focussing  attention  on  the  integrated  sensor  system  design  which  is  an 
important  subset  of  the  overall  ICDT  process.  The  result  of  this  effort 
is  an  interactive  program  capable  of  generating  candidate  sensor  sets 
and  a  means  of  evaluating  the  performance  of  the  sensor  sets.  The 
interactive  program  is  operational  on  Honeywell  and  ASD  computers. 

It  has  been  successfully  used  to  demonstrate  the  design  of  integrated 
sensor  sets.  The  purpose  of  this  section  is  to  describe  and  document 
the  ICDT  demonstration  program.  The  problem  of  determining  integrated 
sensor  sets  to  meet  the  mission  requirements  is  described  first.  The 
integrated  sensor  set  design  procedure  and  the  data  bases  required  for 
implementing  it  are  described  next.  This  is  followed  by  a  discussion  of 
performance  evaluation  of  integrated  sensor  sets.  Implementation  of  the 
demonstration  program  on  the  interactive  computer  is  described  next. 
Finally  an  example  is  given  to  illustrate  the  design  of  integrated  sensor 
sets. 
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4.1  PROBLEM  DEFINITION 


The  design  problem  is  to  seek  a  specification  of  the  sensor  system  which 
will  meet  the  mission  requirements  and  to  determine  how  it  will  be  placed 
and  connected  to  the  avionic  data  processing  hardware.  The  designer 
decides  on  a  particular  aircraft,  the  specific  missions  the  aircraft  will 
have  to  perform,  how  well  they  should  be  accomplished,  and  what  the 
probability  of  survival  of  the  aircraft  itself  should  be  in  accomplishing 
the  missions.  In  addition,  he  may  also  impose  restrictions  on  the  sensor 
systems  available  to  meet  the  above  requirements.  These  restrictions 
might  be  in  the  form  of  quantitative  limits  on  cost,  volume  and/or  weight 
of  the  total  sensor  system  or  they  might  be  a  matter  of  simply  minimizing 
all  of  the  above. 

The  specific  mission  considered  in  this  study  is  the  air-to-ground  delivery 
of  conventional  bombs  and  consists  of  the  following  mission  segments: 

•  Take  off 

•  Climb 

•  Cruise 

•  Detect /Acquire  target 

•  Deliver  weapon 

The  COF  system  provides,  in  general,  the  flight  control,  navigation, 
weapon  delivery  and  effectiveness  management  functions.  Integration  of 
sensors  is  achieved  by  combining  the  measurement  requirements  of  the 
above  C OF  functions. 
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4.2  INTEGRATED  SENSOR  SET  DESIGN  PROCEDURE 


The  problem  of  designing  a  sensor  candidate  set  can  be  divided  into  two 
parts:  generation  of  sensor  candidate  sets  and  evaluation  against  the 
mission  performance  requirements.  The  brute  force  approach,  in  which 
all  possible  combinations  of  sensors  are  considered,  leads  to  a  large 
number  of  candidate  sets  making  them  very  costly  to  evaluate.  The 
following  design  procedure  generates  a  few  candidate  sensor  sets  based 
on  the  eventual  performance  of  the  integrated  COF  system. 

In  the  following,  a  design  procedure  based  on  the  five  classical  steps  of 
the  ICDT  methodology  is  presented  for  the  integrated  sensor  set  design 
problem.  The  procedure  is  described  in  terms  of  the  user /computer 
interaction,  mission  data  base,  sensor  data  base,  sensor  set  generation, 
and  performance  analysis.  A  block  diagram  showing  the  five  steps  in  the 
design  procedure  and  the  interface  with  the  mission  and  sensor  data  bases 
is  given  in  Figure  32 . 

Step  1  of  the  design  process  is  mission  specification.  In  this  step  the 
user  specifies  the  required  mission  parameters  with  the  help  of  the  mission 
data  base.  The  mission  parameters  include  the  control- of-flight  (COF) 
functions  needed  for  the  mission,  the  mission  trajectory  parameters,  the 
sensor  requirements,  the  weapon  characteristics,  and  the  required  target 
probability  of  kill.  In  step  2  of  the  design  process,  projected  measurement 
requirements  for  the  various  COF  functions  are  integrated  to  form  projected 
measurement  requirements  for  the  mission.  Candidate  sensor  sets  are 
generated  in  step  3  to  satisfy  the  projected  measurement  requirements  by 
using  the  sensors  in  the  sensor  data  base.  In  step  4,  the  navigation  and 
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Integrated  Sensor  Set  Design  Process 


weapon  delivery  performance  is  evaluated  for  the  candidate  sensor  sets 
to  check  if  the  required  performance  is  obtained.  The  final  optimization 
of  the  sensor  set  design  is  made  by  the  designer  in  step  5  to  trade  off 
performance  against  cost,  weight,  and  other  sensor  set  characteristics. 
These  steps  in  the  design  process  are  described  in  detail  in  the  following 
sections. 

4.2.1  Mission  Specification  and  Mission  Data  Base 

The  designer /computer  interaction  is  provided  to  specify  the  mission 
performance,  to  select  aircraft,  weapon,  and  target,  and  to  modify  the 
mission  and  aircraft  parameters  defined  in  the  mission  data  base.  Also 
interaction  is  provided  to  modify  the  sensor  selection  criteria  and  the 
sensor  set  physical  restrictions  (for  example,  total  cost,  total  weight,  etc.). 

The  mission  data  base  consists  of  a  library  of  aircrafts,  weapons,  and 
targets  that  are  presented  in  the  form  of  menu  for  selection  by  the  designer. 
It  also  contains  typical  accuracy  and  reliability  requirements  for  the 
measurements  needed  by  the  COF  functions.  As  mentioned  before,  only 
one  specific  mission,  namely,  air-to-ground  delivery  of  conventional 
bombs  is  considered  in  the  demonstration  program.  The  mission  perfor¬ 
mance  is  the  target  probability  of  kill  for  single  shot  bomb  delivery. 

Even  though  three  different  aircrafts,  F-lll,  B-52,  and  F-16,  are 
selectable  from  the  mission  data  base,  the  aircraft  dynamics  is  not  utilized 
and  the  flight  control  is  assumed  to  be  perfect.  Various  targets  and  weapons 
are  available  in  the  mission  data  base.  The  mean  area  of  effectiveness 
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for  the  targets  and  weapons  for  two  different  impact  angles  is  shown  in 
Table  30.  This  information  is  used  by  the  weapon  delivery  performance 
program  to  compute  the  target  probability  of  kill.  The  specific  mission 
trajectory  (see  Figure  33)  is  generated  by  the  trajectory  generator  program 
developed  by  Honeywell  (See  Reference  28).  The  mission  trajectory 
parameters,  namely,  range  to  target,  cruise  altitude,  cruise  speed  and 
weapon  release  altitude,  can  be  specified  to  modify  the  mission  trajectory. 

The  sensor  selection  criterion  consists  of  weighted  combinations  of  cost, 
weight,  volume,  and  power.  This  criterion  is  used  to  eliminate  sensor 
sets  which  are  neither  better  in  quality  nor  in  selection  value  than  the 
baseline  sensor  set.  Also  it  is  used  to  order  the  list  of  candidate  sensor 
sets  for  presentation.  Various  sensor  set  restrictions,  namely,  total 
cost,  total  weight,  total  volume,  and  total  power,  can  be  specified.  These 
are  soft  restrictions  in  that  a  candidate  sensor  set  is  not  eliminated  because 
it  does  not  meet  these  restrictions.  The  restrictions  satisfied  are  indicated 
in  the  list  of  candidate  sensor  sets  presented  to  the  designer. 

4.2.2  Integrated  Measurement  Requirements  and  Sensor  Data  Base 

Sensor  integration  is  achieved  by  combining  the  measurement  requirements 
of  the  COF  functions.  The  measurement  requirements  are  specified  for 
accuracy  and  reliability.  For  the  demonstration  program  the  measurement 
requirements  for  flight  control,  navigation,  and  weapon  delivery  functions 
are  assumed.  Typical  values  for  these  requirements  are  shown  in  Tables 
31  and  32  for  accuracy  and  reliability  respectively.  These  are  modified 
by  the  program  if  the  mission  specification  is  changed  by  the  user.  In 
addition,  the  user  can  specify  which  control- of- flight  functions  are  to  be 
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TABLE  30.  MEAN  AREA  OF  EFFECTIVENESS  OF  WEAPON  TARGET  COMBINATIONS 


I 


TARGETS  | 

GROUND  TO 

GROUND 

ROCKET 

19000 

43000 

30500 

60000 

36700 

76000 

48000 

103000 

60500 

142000 

25000 

14000 

46900 

28000 

ARMOURED 

PERSONNEL 

CARNER 

837 

1370 

1300 

2180 

1670 

2730 

2090 

5000 

3130 

6040 

904 

768 

2000 

2370 

ARTILLERY 

2610 

6360 

4560 

10400 

5520 

12900 

7830 

20400 

10800 

27600 

3180 

2550 

7100 

9000 
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LAUNCHER 
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MISSION  TRAJECTORY  PARAMETERS 


Figure  33.  Specific  Mission  Trajectory  used  for  the  ICDT  Demonstration  Program 


integrated  and  the  program  combines  the  individual  requirements  to  get 
integrated  measurement  requirements.  These  are  also  shown  in  Tables 
31  and  32.  Finally,  the  user  can  modify  these  integrated  measurement 
requirements  before  generating  candidate  sensor  sets. 

The  simple  sensor  data  base  developed  for  this  demonstration  program  is 
defined  in  the  following.  Four  types  of  sensors  are  chosen  to  be  included 
in  the  sensor  data  base.  These  are  body  rate  sensors,  body  acceleration 
sensors,  airdata  sensors,  and  target  acquisition  and  tracking  sensors. 

The  sensor  data  base  contains  sensors  manufactured  by  different  companies. 
The  accuracy  data  for  the  measured  variables  for  each  sensor  in  the  data 
base  are  shown  in  Table  33.  The  reliability  of  these  measurements  is 
calculated  from  the  mission  duration  and  the  mean  time  between  failure 
(MTBF)  data  for  the  sensors.  In  addition  to  this  MTBF  data,  the  cost, 
weight,  volume,  and  power  requirement  data  for  the  sensors  are  shown 
in  Table  34. 

4.2.3  Generation  of  Candidate  Sensor  Sets 

The  problem  of  generating  sensor  candidate  sets,  for  the  purpose  of  evaluating 

them  for  sensor  integration,  is  an  important  one.  The  brute  force  approach, 

in  which  all  possible  combinations  of  sensors  are  considered,  leads  to  a 

very  large  number  of  candidate  sets  making  them  almost  impossible  to 

evaluate.  Consider,  for  example,  a  control-of-flight  system  which  needs 

N  independent  sensor  measurements.  If  the  sensor  data  base  contains  10 

different  sensors  for  each  of  these  measurements,  then  the  number  of 

N 

possible  sensor  combinations  is  given  by  10  .  Thus  the  need  exists  for  a 
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TABLE  33.  SENSOR  MEASUREMENT  ACCURACY  DATA 
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sensor  selection  procedure  to  determine  the  sensor  candidate  sets  based 
on  the  eventual  performance  of  the  integrated  control- of-flight  system.  A 
block  diagram  of  the  sensor  selection  procedure  is  shown  in  Figure  34. 

The  sensor  set  selection  procedure  reduces  the  number  of  possible  candidate 
sensor  sets  to  a  manageable  number,  by  using  the  projected  measurement 
requirements  and  the  sensor  selection  criteria.  It  considers  all  possible 
combinations  of  sensor  sets  and  presents  the  designer  with  only  a  few 
candidate  sets  so  that  he  can  evaluate  them  with  detailed  performance 
analysis  to  make  sure  that  they  satisfy  the  mission  performance.  The 
description  of  the  sensor  selection  algorithm  is  given  in  Appendix  A  and 
is  summarized  here  as  a  three  step  process. 

1.  Form  a  baseline  candidate  sensor  set  with  the  most  accurate 
sensors  and  with  reliability  requirements  satisfied  by  using 
redundant  sensors. 

2.  Generate  candidate  sensor  sets  whose  accuracy  or  selection 
value  is  better  than  that  of  the  baseline  set. 

3.  Determine  the  sensor  restrictions  satisfied  and  present  the 
candidate  sensor  sets  according  to  the  sensor  selection  value. 

4.2.4  Navigation  and  Weapon  Delivery  Performance 

The  quality  of  sensors  in  the  sensor  candidate  set  is  used  to  determine  the 
mission  performance.  A  block  diagram  of  the  steps  in  evaluating  the 
performance  of  the  mission  is  given  in  Figure  35.  The  navigation  sensor 
quality  and  the  mission  trajectory  are  used  by  the  navigation  performance 
program  (NAVCOV)  to  evaluate  the  navigation  error  (CEP)  at  the  end  of 
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e  35.  Mission  Performance  Evaluation  Process 


midcourse.  This  information  and  the  target  acquisition  sensor  quality  are 
used  to  compute  the  probability  of  target  acquisition  and  also  the  tracking 
error  (CEP)  until  the  weapon  is  released.  Finally,  the  tracking  error 
and  the  mean  effective  radius  of  the  target-weapon  combination  are  used 
to  compute  the  probability  of  target  kill,  which  is  the  mission  performance. 

Navigation  performance  is  computed  by  using  NAVCOV  software  developed 
by  Honeywell  (See  Reference  28).  NAVCOV  is  a  covariance- based  program 
and  has  proven  effective  in  predicting  the  performance  of  inertial  systems. 

The  various  sensor  errors  that  can  be  used  for  propagating  the  covariance 
include  bias  errors,  scale  factor  errors,  misalignment  errors,  gyro 
g-sensitive  errors,  and  accelerometer  nonlinearity  errors.  Only  bias 
errors  were  considered  for  the  demonstration  program  to  compute  the 
navigation  performance. 

Weapon  delivery  performance  is  obtained  by  using  the  simplified  models 
developed  under  this  study  to  compute  probability  of  acquisition  and 
probability  of  target  kill.  These  models  are  presented  in  Appendix  B. 

4.2.5  Interactive  Program  Implementation 

The  demonstration  program  consists  of  six  modules  (see  Figure  36)  organized 
as  an  overlayed  or  segmented  program  by  the  executive  or  main  program 
to  meet  the  interactive  memory  requirements.  The  interface  between 
the  user,  the  data  base  files,  and  the  six  program  modules  is  shown  in 
Figure  36.  The  interactive  program  is  currently  operational  on  two 
computers,  Honeywell  GCOS-B  and  the  ASD  computer  (NOSBE).  The  segment 
load  directives  to  set  up  the  interactive  program  on  the  ASD  computer  are 
shown  in  Table  35. 
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Figure  36.  Interactive  Program  Organization 
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The  question  and  answer  method  of  interaction  was  used  in  developing  the 
demonstration  program.  All  input  from  the  user  is  in  free  format.  At 
each  step  of  the  interaction,  the  program  presents  a  menu  of  options  and 
prompts  the  user  to  pick  one  of  the  options.  In  some  instances  the  program 
prompts  for  a  yes  (y)  or  no  (n)  type  of  response. 

In  the  following  section  a  demonstration  example  is  given  to  illustrate  the 
sensor  set  design  process. 

4.2.6  Integrated  Sensor  Set  Design  ExampL- 

Use  of  the  ICDT  demonstration  program  is  illustrated  by  designing  integrated 
sensor  sets  for  the  air-to-ground  conventional  bomb  delivery  mission.  The 
actual  user /computer  interaction  for  this  example  is  given  in  detail  in 
Appendix  C.  Here  only  the  design  process  is  explained. 

The  mission  specifications  used  in  the  example  are  given  in  the  following: 

•  Aircraft  used  =  F-16 

•  Target  =  Ground-to-ground  rocket 

•  Weapon  =  Mk  84 

•  Mean  effective  radius  =  163  ft. 


•  Target  kill  probability  =0.8 


The  following  are  the  trajectory  parameters  used  to  define  the  actual 
mission  trajectory: 

•  Range  to  target  150  nm 

•  Cruise  altitude  20000  ft 

•  Cruise  speed  500  knots 

•  Weapon  release  altitude  =  5000  ft 

All  three  control- of- flight  functions,  namely,  flight  control,  navigation, 
and  weapon  delivery,  are  chosen  for  sensor  integration.  The  integrated 
measurement  requirements  are  shown  in  Table  36.  The  sensor  selection 
criterion  is  based  on  cost  alone  and  the  sensor  set  restrictions  are  as 
follows: 

•  Total  cost  =$50000 

•  Total  weight  =  400  lbs. 

•  Total  volume  =  6500  cin 

•  Total  power  =10000  Watts 

The  integrated  candidate  sensor  sets  generated  by  the  program  are  shown 
in  Table  37.  Since  the  sensor  data  base  contains  only  four  different  types 
of  sensors,  the  sets  which  contain  more  than  four  sensors  have  redundant 
sensors.  Also  note  that  the  number  of  possible  sensor  sets  (without 
considering  redundancy)  is  given  by  3  x  3  x  4  x  5  =  180  (based  on  the 
number  of  sensors  of  each  type  in  the  sensor  data  base).  If  redundancy 
is  considered,  the  number  of  possible  sensor  sets  would  be  even  higher. 
The  program  presents  only  24  sensor  sets  (see  Table  37)  for  consideration 


TABLE  36 


INTEGRATED  MEASUREMENT  REQUIREMENTS 


NO 

MEASUREMENT 

ACCURACY  NEEDED 

RELIABILITY  NEEDED 

1 

AIRSPEEO  (KNOTS) 

15.0000 

.9800 

2 

ALTITUDE  (FEET) 

SO.OOOO 

.9800 

3 

AZIMUTH  (MRAD) 

1.7000 

.9900 

4 

ELEVATION  (MRAO) 

3.2000 

.9900 

5 

RANGE  (FEET) 

16.0002 

.9900 

6 

ROLL  RATE (OEG/HR) 

.0800 

.9980 

7 

PITCH  RATE  (OEG/HR) 

.0800 

.9980 

8 

YAW  RATE  (OEG/HR) 

.0800 

.9980 

9 

LONG  ACCN  (MG) 

.0170 

.9900 

10 

LATE  ACCN  (MG) 

.0170 

.9900 

11 

VERT  ACCN  (MG) 

.0170 

.9900 

TABLE  37.  INTEGRATED  CANDIDATE  SENSOR  SETS 


1 


RESTRICTIONS 

SATISFIED 

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.11.0.0. 

ii§§§iii3i§3iiiiiiilliil 

oouooooouoooooo 

ACCURACY 

UALUE 

mw^JschPwcvirooorocDcuawororoaovovoro'O'VO*- 
ro  9«  ot  n  ««  n.  9t  n.  in  m  k  ro  oj  a>  rw  ro  <D  vo  in  r<>  v> 
oi  w  w  ♦  po  ro  ro  *■  *■  «  +■  tn  ro  ro  <*•  w  *  ♦  !*  5>  in  K  so 

CD  CD  CD  O  CD  CD  CD  QD  CD  QD  CD  CD  CD  O  OD  SI  CD  CD  CD  O  CD  O  O  0 

RELIABILITY 

UALUE 

UXMNOVMWNMCDWMNn^ONnNfnOKn 
ooci>N«B0a>«>«Nao«aBOS(Baoc»a»Na»o 
CD  CD  CD  QD  ^D  QD  CD  ^D  CD  ^D  CD  CD  ^D  ^D  CD  ^D  ^D  CD  QD  ^D  CD  CD  QD  CD 
a  CD  ®  CD  CD  QD  CD  CD  CD  ^D  CD  CD  ^D  CD  CD  ^D  CD  Q)  QD  CD  ^D  ^D  ^D  ^D 

•  m  CD  CD  CO  CO  CO  CD  CD  CD  ®  00  CD  CD  CD  00  CD  CD  CD  CD  CD  W  0»  ® 

SELECTION 

UALUE 

^D  CD  ^D  QD  CD  CD  C^^  C^^  ^D  C^}  CD  CD 

®  CD  CD  ©  Q>  CD  ©  ©  q  d  CD  ^D  CD  ^D  CD  ^D  ^D  CD  CD  CD  CD  CD  CD 
CD  Q)  CD  ©  CD  CD  ^D  ^D  CD  ^D  Q^  CD  QJ  ^D  CD  ^D  CD  ^D  CD  CD  CD  CD  CD  CD 
Q)  QD  Q>  Q>  9  CD  qjj  Qg;  CD  CD  QD  ^D  CD  ^D  CD  CD  CD  CD 

CD  CD  CD  CD  CD  CD  CD  C^D  CD  CD  Cl^  QD  CD  Q^  CD  QD  CD 

9  ®  CD  CD  CD  9  QD  ^D  ^D  ®  CD  QD  ^D  ^D  CD  ^D  ^D  CD  ^D  QD  CD  QD  ^D  CD 
fw  CD  9t  «NJ  CD  M  <r*  OJ  CM  in  CM «  IS-  ®  W  <M  CD  f-0  9*  CM  CM  W  CM  IO 

ao  ov  9%  oo  cm  cm  <m  r*»  ro  ra  c©  wo  oo  <*  o>  co  <m  m  cm  m  n  n  to  to 
CMCMCMrororororororororo^M-'M-ininininininininin 

NUNBER 

OF  SENSORS 

in  m + *>  in  in  in  *■  tt>  *■  w  min  m  ♦  *•  m in  m  ♦  m *■  m  m 

SET 

NUNBER 

— <m  w  ^  « vo  pw  oo  <rs  CD  *h  <vj  ro  ♦  in  vo  Pw  oo  »i  #  r!  M  w  ♦ 

235 


t 

! 

i 


t 


I 


t 


•wr-nST 


of  the  designer.  The  sensor  sets  are  all  arranged  according  to  the  cost 
because  the  selection  criterion  was  based  on  cost  alone.  Accuracy  value 
gives  an  approximate  feel  for  the  performance  capability  of  the  sensor 
sets.  The  last  column  of  Table  37  indicates  which  of  the  sensor  set 
restrictions  are  satisfied. 

To  evaluate  the  mission  performance,  first  sensor  set  number  1  with  a 
total  cost  of  $28,  700  is  chosen.  The  probability  of  kill  obtainable  with 
this  set  comes  to  only  0.1184.  So  a  more  accurate  sensor  set  is  needed  to 
meet  the  performance  specification.  According  to  Table  37,  candidate  sen¬ 
sor  set  number  10  with  a  cost  of  $32,500  has  the  highest  accuracy  value 
and  at  the  same  time  satisfies  all  the  restrictions.  With  this  set  the 
probability  of  kill  is  0.78C7,  which  is  close  to  the  required  mission  per¬ 
formance  (0.8).  Table  37  shows  that  sensor  set  number  22  with  a  cost  of 
$53,  500  has  the  highest  accuracy  value  of  ail  the  sets  and  with  that  set 
the  probability  of  kill  obtainable  is  0.7967.  The  cost  and  performance  of 
the  above  three  sets  are  summarized  in  Table  38. 

4.2.7  Integrated  vs.  Nonintegrated  Design 

It  is  possible  to  use  the  ICDT  demonstration  program  to  get  an  approximate 
indication  of  the  differences  between  integrated  and  nonintegrated  sensor 
set  designs.  If  in  the  above  example  the  sensor  set  design  process  is 
repeated  each  time  with  only  one  of  the  control- of-flight  functions,  then 
candidate  sensor  sets  will  be  generated  by  the  program  for  the  nonintegrated 
COF  functions  separately.  However,  the  mission  performance  cannot  be 
evaluated  since  the  sensor  candidate  sets  are  not  complete  individually 
to  meet  the  measurement  needs  of  the  mission.  If  the  lowest  cost  sensor 
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sets  for  each  control- of-f light  function  are  combined,  then  they  can  be 
compared  with  the  lowest  cost  sensor  set  obtained  for  the  integrated 
control -of -flight  function.  This  comparison  is  shown  in  Table  39.  In 
this  example  the  integrated  sensor  set  design  results  in  the  elimination 
of  two  sensor  components. 


TABLE  39.  COMPARISON  OF  NONINTEGRATED  SENSOR  SET  AND 
INTEGRATED  SENSOR  SET  DESIGN 


FLIGHT  CONTROL  NAVIGATION  WEAPON  DELIVERY 


1 

HONEYWELL 

■ 

AIRDATA 

LASER  RATE 

HONEYWELL 

1 

GYRO 

AIRDATA 

RATE 

1 

GYRO 

ACCELEROMETER 

FIRE  CONTROL 

I 

QA  2000 

RADAR 

■ 

ACCELEROMETER 

1 

2160 

NONINTEGRATED 
SENSOR  SET 


HONEYWELL 

AIROATA 


RATE 

GYRO 


ACCELEROMETER 
QA  2000 


LASER  RATE 
GYRO 


INTEGRATED 
SENSOR  SET 
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SECTION  5 


RECOMMENDATIONS  FOR  FUTURE  DEVELOPMENT 


The  current  program  identified  and  discussed  the  various  techniques 
available  for  integrated  control  design  and  developed  an  approach  (ICDT) 
for  the  integration  of  control-of-flight  systems.  The  techniques  are 
summarized  in  Table  40.  A  methodology  was  developed  for  integrated 
sensor  set  design  and  was  demonstrated  on  an  interactive  computer.  Any 
future  development  should  start  from  this  foundation  and  extend  the 
methodologies  and  the  data  bases  for  effectively  designing  integrated  control 
design  for  future  tactical  aircrafts.  The  specific  recommendations  for  the 
next  phase  of  development  are  given  in  the  following: 

•  Model  and  Algorithm  Development 

--Develop  reliability  analysis  model  for  hybrid  system 
architectures  (hardware  +  software) 

--Develop  algorithms  for  redundancy  management  schemes 
(analytic  redundancy,  fault  detection,  hardware  redundancy, 
etc. )  with  consideration  for  reliability,  survivability,  and 
performance 

— Develop  algorithms  for  integrated  computational  schemes 
(simplified  Kalman  filters)  to  improve  reliability  and  per¬ 
formance 
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--Generalize  the  sensor  selection  algorithms  to  include  -’-iteria 
for  selecting  architecture,  redundancy  management,  ant 
integrated  computation  schemes  along  with  sensors 

--Develop  techniques  for  in-flight  effectiveness  measurement 
and  management 

Data  Base  Development 

--Develop  a  first-level  architecture  data  base  with  consideration 
for  reliability,  survivability,  and  performance;  include 
failure  rate  data  for  different  architectures 

--Expand  the  current  sensor  data  base  to  include  terrain 
following  sensors,  GPS  and  other  radio  sensors;  include 
MTBF  and  vulnerability  data  for  sensors 

--Include  actuators  and  data  processing  functions  in  the  data  base 

Performance  Evaluation 

--Refine  the  algorithms  for  system  effectiveness  evaluation 
using  the  extended  WSIEAC  approach 

--Parameter /structural  sensitivity  analysis 

--Develop  simplified  algorithms  for  computing  probability 
of  kill  (P.  )  and  probability  of  survival  (P  )  for  the  selected 
mission 

--Develop  simplified  algorithms  for  computing  the  life- cycle 
cost 

--Develop  simplified  algorithms  for  survivability  evaluation 
using  simple  threat  models  and  vulnerability  data  for  sensors 
and  other  hardware 


--Develop  algorithms  for  reliability  evaluation  using  SESIP 
approach  which  utilizes  MTBF  data  for  sensors  and  failure 
rates  for  architectures 

--Develop  simplified  algorithms  for  evaluating  dependability, 
availability,  and  capability  of  the  system. 

Demonstrate  ICDT  on  future  tactical  aircraft 
--Develop  mission  data  base  for  generic  fighter 
--Develop  system  architecture 
--Optimize  life-cycle  cost 
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APPENDIX  A 


SENSOR  SELECTION  ALGORITHMS 


INTRODUCTION 

The  problem  of  selecting  sensor  candidate  sets,  for  the  purpose  of  evaluating 

them  for  sensor  integration,  is  an  important  one.  The  brute  force  approach, 

in  which  all  possible  combinations  of  sensors  are  considered,  leads  to  a 

very  large  number  of  candidate  sets  making  them  almost  impossible  to 

evaluate.  Consider,  for  example,  a  control -of -flight  system  which  needs 

N  independent  sensor  measurements.  If  the  sensor  data  base  contains  10 

different  sensors  for  each  of  these  measurements,  then  the  number  of 

N 

possible  sensor  combinations  is  given  by  10  .  Thus  the  need  enisls  for  a 
sensor  selection  procedure  to  determine  the  sensor  candidate  sets  based 
on  the  eventual  performance  of  the  integrated  control-of-flight  system. 

In  the  following  a  sensor  selection  procedure  is  presented,  based  on 
reliability  and  accuracy  considerations,  to  reduce  the  possible  sensor  sets 
to  a  manageable  number.  In  addition,  a  sensor  selection  value,  based  on 
the  weighted  sum  of  cost,  weight,  volume,  and  power  requirements  of  the 
sensors,  is  used  to  aid  in  the  selection  procedure.  In  the  following,  the 
definitions  of  various  quantities  used  and  their  calculations  are  described 
first.  This  is  followed  by  a  detailed  description  of  the  sensor  selection 
procedure. 


us 
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MEASUREMENT  ACCURACY  AND  RELIABILITY  VECTORS 

These  are  represented  by  vectors  and  r^  and  the  elements  a^ (j )  and  rr(j) 
correspond  to  the  measurement  accuracy  and  reliability  required  for  the 
parameter  j  to  be  measured  for  the  mission.  The  list  of  parameters  to  be 
measured  and  the  measurement  accuracy  and  reliability  values  for  the 
conventional  weapon  delivery  mission  are  given  in  Tables  31  and  32.  As 
an  example,  j  =  2  corresponds  to  the  altitude  parameter  and  the  values  of 
ar(2)  and  1*^(2)  for  the  flight  control  function  are  given  by  50.0  ft  and  0.98. 

SENSOR  ACCURACY  AND  RELIABILITY  MATRIXES 

These  are  represented  by  matrixes  A  and  R  and  the  elements  A  (i,  i) 

th  s  s  s 

and  R  (j,  i)  correspond  to  the  i  sensor  accuracy  and  reliability  with 
s 

respect  to  the  parameter  j.  Since  it  is  normal  practice  to  specify  mean 
time  between  failures  (MTBF)  data  for  the  sensors,  a  simple  procedure 
is  used  to  calculate  the  reliability  of  the  sensors  and  is  given  in  the 
following. 

RELATIONSHIP  BETWEEN  MTBF  DATA  AND  RELIABILITY  OF  SENSORS 


The  probability  that  a  sensor  will  fail  at  time  t  during  its  operation 
(assuming  normal  distribution)  is  given  by 


P 


f 


_ L_  e- 

2a2 


(la) 


k  i 
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where  p,  is  the  mean  time  between  failures  (MTBF) 
a  is  the  standard  deviation 


Since  sensor  reliability  is  characterized  by  MTBF  data,  we  will  assume 
that  the  standard  deviation  a  is  proportional  to  MTBF  (p,).  Now,  if  the 
duration  of  the  mission  is  at  At,  then  the  maxiumum  probability  that  the 
sensor  will  fail  during  the  mission  is  given  by 

^7-  dt  (lb) 

2n 

which  can  be  simplified  to 


f  V2tt  p, 


At 


and  the  sensor  reliability  is  given  by 


r  =  1 


(lc) 


(Id) 


This  simple  relationship  is  used  to  determine  the  sensor  reliability  from 
MTBF  data  and  mission  duration. 


SENSOR  SET  ACCURACY  AND  RELIABILITY  VECTORS 


Since  we  are  dealing  with  sensor  sets  and,  in  general,  a  sensor  set  will 
consist  of  more  than  one  sensor,  it  is  necessary  to  integrate  the  individual 
sensor  accuracies  and  reliabilities  into  a  sensor  set  accuracy  and  reliability. 
This  will  later  facilitate  comparisons  between  sensor  sets. 


The  sensor  set  accuracy  and  reliability  vectors  are  represented  by  a  and 

s 

r  and  the  elements  a  (j)  and  r  (j)  correspond  to  the  sensor  set  accuracy 
s  s  s 


and  reliability  for  the  parameter  j. 


If  there  are  n  sensors  in  the  sensor  set  which  measures  parameter  j,  then 

54 

the  probability  that  measurement  parameter  j  is  not  available  is  given  by 


ps<j>  -  w  ps<i-  *> 


where  P  (j,  i)  is  the  probability  of  i  sensor  failure  to  measure  parameter 
s 

j  and  is  given  by 


P3(j.  i>  ■  i  -  r3<j.  t) 


Hence  the  reliability  of  measurement  parameter  j  for  the  sensor  set  is 
given  by 


rs(j)  •  1  -  Ps<J> 


A.  Papoulis,  Probability,  Random  Variables  and  Stochastic  Processes, 
McGraw  Hill,  1965. 
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The  accuracy  of  measurement  parameter  j  for  the  sensor  set  is  computed 
as  a  reliability  weighted  number  and  is  given  by 


n 


as(j)  = 


E  A  (j,  i)  P  (j.  i) 
i=l  s  s 


n 


&  p3(i- » 


(5) 


For  example,  if  there  are  two  sensors  in  a  sensor  set  which  measure  the 
altitude  with  accuracies  of  40  ft  and  10  ft  and  reliabilities  of  0.  9  and  0.8 
respectively,  then  the  accuracy  and  reliability  value  of  the  sensor  set 
for  altitude  measurement  is  given  by 


as<2) 

r  (2) 
s 


40  x  0.9  +  10  x  0.8  _  OR  Q 
0.9  +0.8  '  1 

1  -  (1  -  0.9)  (1  -  0.8)  =  0.98 


(6) 

(7) 


SENSOR  SET  ACCURACY,  RELIABILITY,  AND  SELECTION  VALUES 


As  a  further  aid  in  the  sensor  set  selection  procedure  the  following 
quantities  are  defined.  Sensor  set  accuracy  value  is  an  indicator  of 
excess  accuracy  of  the  sensor  set  and  is  defined  by  the  following 
expression 


m 

«  E 

j=i 


ar<3> 


as<3> 


ar(j) 


(8) 


where  m  is  the  number  of  measurements. 


Sensor  set  reliability  value  is  an  indicator  of  excess  reliability  of  the 
sensor  set  and  is  defined  by  the  following  expression 

m 

rs =  £1  ra(j)  ■  rr(i)  (9) 

In  addition  to  accuracy  and  reliability,  sensors  are  characterized  by  cost, 
weight,  volume,  and  power  requirements.  Sensor  set  selection  value  is 
a  collective  indicator  of  these  characteristics  and  is  defined  by 

n 

J  ■  y.  w  xc(i)+w  xw(i)+w  xv(i)+w  x  p(i)  (10) 

C  W  V  p 

where  n  is  the  number  of  sensors  in  the  sensor  set,  w  ,  w  ,  w  ,  and  w 

c  w'  v  p 

are  the  weightings  on  cost,  weight,  volume,  and  power  respectively,  and 
c(i),  w(i),  v(i)  and  p(i)  are  the  actual  cost,  weight,  volume,  and  power 
requirements  of  sensor  i. 

SENSOR  SELECTION  PROCEDURE 

The  purpose  of  the  sensor  selection  procedure  is  to  consider  all  possible 
combinations  of  sensor  sets  and  present  the  designer  with  only  a  few 
candidate  sets  so  that  he  can  evaluate  them  with  detailed  performance 
analysis  to  make  sure  that  they  satisfy  the  performances  required  by  the 
mission. 
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In  the  following  the  sensor  selection  procedure  is  described  as  a  three  step 
process.  The  organization  of  the  procedure  is  presented  in  Figure  A-l. 

The  first  step  generates  a  base  line  candidate  set;  the  second  step  generates 
all  combinations  of  sensor  sets  and  compares  then  with  the  base  line  set, 
and  the  third  step  presents  the  candidate  sets  to  the  designer. 

In  the  first  step,  sensors  (i)  whose  accuracies  A  (j,  i)  are  not  within  a 

s 

specified  band  of  the  required  measurement  accuracies  a^(j)  for  any  of 
the  parameters  j  are  eliminated  from  further  consideration.  This  reduces 
the  number  of  sensor  set  combinations  that  need  to  be  considered.  Next 
a  baseline  candidate  set  with  the  best  accuracies  available  among  the 
remaining  sensors  is  generated  and  is  displayed  to  the  designer.  Finally, 
redundant  sensors  are  introduced  into  the  baseline  candidate  set  if  necessary 
to  satisfy  the  required  measurement  reliabilities  rr(j)  for  all  j.  Up  to  a 
maximum  of  four  redundant  sensors  are  allowed. 

In  the  second  step,  all  possible  combinations  of  sensor  sets  are  generated. 
Those  sensor  sets  which  do  not  satisfy  the  measurement  accuracy  require¬ 
ments  are  dropped  from  further  consideration.  Redundant  sensors  are 
added  if  necessary  to  meet  measurement  reliability  requirements.  Those 
sensor  sets  whose  selection  value  is  better  than  that  of  the  baseline  set  are 
retained  as  candidate  sensor  sets. 

In  the  third  step,  the  candidate  sensor  sets  are  further  checked  to  see  if 
they  meet  the  sensor  set  restrictions  on  cost,  weight,  volume,  and  power. 
The  candidate  sets  are  ordered  according  to  the  selection  value  and 
presented  to  the  designer  for  sensor  set  performance  evaluation. 


1 


Figure  A-l.  Organization  of  the  Three  Step  Procedure  for  Sensor 
Selection 
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APPENDIX  B 


WEAPON  DELIVERY  PERFORMANCE  MODELS 


Simplified  models  for  computing  probability  of  acquisition  and  probability 
of  target  kill  are  presented  in  the  following.  These  models  assume  that 
the  weapon  is  delivered  during  level  maneuver. 

ACQUISITION  PROBABILITY  MODEL 

Given  a  sensor  with  +  0^  in  elevation  and  +  0^  in  azimuth,  with  a  nominal 
depression  angle  v  in  search,  the  probability  that  the  desired  target  is  in 
the  field  of  view  at  a  designated  time,  t,  is  dependent  upon  the  navigation 
accuracies  (0^,  ©2  and  y  in  radians). 

Let  o  be  the  navigation  error  along  the  line  from  the  designated  search 

point  to  the  expected  target  position,  and  a  be  the  error  at  right  angles 

NXR 

to  this  line. 


The  probability  that  the  target  is  within  the  lateral  search  limits  is: 


(HA/siny  )*02 


P  =2 
XR 


/ 


NXR 


V" 2n 


1  -x  12 

e  dx 


(9) 


The  probability  that  the  target  is  within  the  down  range  search  limits 
for  a  snapshot  search  is: 


PR 


HAsin(v-61) 

a 

NR 


y~2^ 


1  ~x2/2 

e  dx 


(10) 


-HAsin(v+61) 


NR 


If  the  search  is  to  be  conducted  for  a  time  t,  in  advance  of  having  the 
expected  target  in  the  center  of  the  FOV,  until  a  time  after  the  expected 
target  was  at  the  center  of  the  field  of  view,  the  probability  becomes; 


? 


(HA  .  sintv-Sj)  +  V vA>/aNR 


•x2/2  dx 


V  2tt 


-(HAsta(Y+8j)  +tj  .  Va)/onr 


(11) 


Total  probability  of  acquisition  thus  becomes 

PT  =  PXR  X  PR  °r  PXR  X  Pr'  (12) 

In  practice,  the  limits  on  the  FOV  also  depend  upon  the  ability  of  the 
delivery  system  to  engage  a  detected  target.  Detections  made  outside 
the  engagement  envelope  are  not  true  acquisitons,  although  such  detections 
could  reduce  cr^  and  for  a  subsequent  acquisition. 

I 


TARGET  PROBABILITY  OF  KILL  MODEL 


Given  the  nominal  parameters  for  conventional  weapon  delivery 
Altitude  (feet) 

VA  Airspeed  (fps) 

Rc  Slant  range  at  release  (ft) 

TOF  Time  of  fall  (see) 

6_  Terminal  impact  angle  (°) 
b 

and  the  various  errors  (1  sigma  values)  associated  with  weapon  delivery 


c 

a 

< 

Altitude  error  (ft) 

avaz 

Vertical  velocity  error  (fps) 

4Vay 

Lateral  velocity  error  (fps) 

4Vax 

Airspeed  error  (fps) 

WR 

Roll  angle  error  (rad) 

a, 

«- 

<1 

Pitch  angle  error  (rad) 

A0 

Y 

Yaw  angle  error  (rad) 

aRs 

Slant  range  error  (ft) 

Depression  angle  error  (rad) 

‘♦a 

Azimuth  angle  error  (rad) 

AS 

Ballistic  error  (rad) 

t 


1 


AV„.  Wind  error  (fps) 
w 

AT  Timing  error  at  release  (sec) 

R 

the  following  range  and  cross  range  error  components  can  be  defined. 


1 

AH.  .  TOF  .  VA  .  cos  6 

A  A  F 

ha 

(range  comp) 

'2 

AVaz  .  TOF  .  sin  0^, 

(range  comp) 

3 

avAY  .  TOF 

(cross  range  comp) 

4 

iVAX  .  TOF 

(range  comp) 

5 

mr  •  ha 

(cross  range  comp) 

6 

Rs/HA 

(range  comp) 

7 

^  -VRs  -  V 

(cross  range  comp) 

8 

4Rs  ’  rs/Vrs2-ha2 

(range  comp) 

9 

%  •  Rs  /  ha 

(range  comp) 

10  " 

4*a  •Vrs2-ha2 

(cross  range  comp) 

11  = 

AP  .  Rg  /  sinO^, 

(range  comp) 

12  " 

AB  .  Rg 

(cross  range  comp) 
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*13  -  AVW  .  TOF 

(range 

comp) 

S14  =  *TR  *  VA 

(range 

Then  the  impact  CEP  is  given  by 

-.1  2  ^  2  .  2  2  2  ,  2 
"r  SV‘l  +  ‘2  +  ‘4  +  e6  +  *8  +  ‘9 

+  e  2  +  c  2  +  e 
*11  +  13  + 

XR 


13 


(14) 


(15) 


CEP  =  1.1774 V-'b  +  'J. 


R  XR 

and  the  components  of  the  probability  of  kill  is  computed  by 

MER 


KA 


=  2 


/ 


R 


V  2tt 


-x2/2 

e  dx 


(16) 


(17) 


KB 


MER 
■  a. 


=  2 


/  »  j_ 
o  V  2tt 


-x2/2  . 

e  dx 


(18) 


where  MER  is  the  mean  effective  radius  of  the  target-weapon  combination. 
Finally  the  target  probability  of  kill  is  given  by 


PKT  =  PKA *  PKB 


(19) 


The  above  probability  models  are  used  for  computing  the  weapon  delivery 
performance. 
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DEMONSTRATION  OF  THE  INTERACTIVE  PROGRAM  FOR 
INTEGRATED  SENSOR  SET  DESIGN 
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Example  2;  Descriptor:  aircraft  sensor  integration 
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